snoyberg / packdeps Goto Github PK

streamly-fsnotify ought to be listed in the reverse dependencies of streamly, among other places. It's own list is present.

The potential reasons for packdeps to have gotten confused include the package recently being deprecated, changing ownership, then being un-deprecated.

It would be nice to also show what the latest version of a package would break. This is mostly of interest to packagers where it would be nice to know that neither-0.2.0 shouldn't be pushed since it would break the latest persistent (for instance).

packdeps reports addressing the constraint to include binary | 0.10.0.0.

But binary 0.9 and binary 0.10 releases were deprecated:
http://hackage.haskell.org/package/binary/preferred

This issue prevents some automation.

Reference:
The list is at: http://hackage.haskell.org/packages/preferred-versions
And the Hackage API you know way better than I, who does not have a clue.

Thank you greatly.

Entries in Atom feeds have links like https://packdeps.haskellers.com/feed/exact:hakyll/hakyll/4.14.0.0/2021-07-19%2005:37:30%20UTC When I open that link in browser, I am immediately redirected to the Hackage page for the package. This is inconvenient: the reason I'm subscribed to the feed is that I want to know which of my deps are outdated, and now I have to manually go to packdeps.haskellers.com to figure that out. It'd be much more convenient to me if the Atom entry linked me to https://packdeps.haskellers.com/feed?needle=exact%3Ahakyll

It appears that the redirect was there from day 1 (Handler.Home.getFeed3R), so this is probably intentional. I'd like to know the reason and see if it can be reconsidered.

Thank you for a nice and useful service!

For example if you have

if flag(tests)
  build-depends: HUnit == 1.1.*

packdeps never checks the HUnit dependency.

For example, if I want to know what outdated dependencies snap has, currently I have to scroll through half a dozen when I've just searched for snap

If I visit http://packdeps.haskellers.com/feed?needle=hlint I get told hlint has a restrictive bound on ghc 8.6.5. That's weird since hlint can depend on 8.8.*, but not 8.6 at all. I can't see how packdeps came to that conclusion.

I'd like to add support for packdeps to Syntastic for Vim, such that when editing a Cabal file you'd get warning markers next to lines for outdated dependencies. For this it would be nice if packdeps could include the line and column number for each outdated dependency.

I realize this might not be easy since, I assume, Cabal doesn't keep that information when parsing a Cabal file, but anyway. Maybe I should file a request for that to upstream Cabal?

I'll make the PR if the change is welcome

Cought me as bad surprise in ghci

No PR yet, possibly related to #25. http://packdeps.haskellers.com/feed?needle=hledger reports on all packages containing "hledger" in their name, which is a nice feature. But, it always shows hledger-vty and hledger-chart as outdated. These packages are marked deprecated on hackage. Perhaps packdeps should just ignore deprecated packages.

To gauge the impact of API changes, I wanted to check if there is anything else besides stack, cabal2nix and tinc that depends on hpack. But when I look at

http://packdeps.haskellers.com/reverse/hpack

then I don't see stack in the list. Is there a good reason for this or is it a bug?

Would it be possible to have the cli version of packdeps check all dependencies except for a specified list? I ran into this recently where one package (specifically fgl-arbitrary) depended upon an as-yet-unreleased version of another package (fgl), thus causing the travis-ci build to fail.

Recently license tracking was added to the web interface. How hard would it be to expose this in the command line tool as well? That would be useful for using it on internal packages.

This may not be packdeps' fault but I just note that it does not build from git with hackage:

[packdeps]$ cabal install
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: packdeps-yesod-0.0.0
trying: lens-3.10
trying: bifunctors-4.1.0.1
trying: classy-prelude-conduit-0.6.0
trying: classy-prelude-0.6.0
trying: vector-instances-3.3
trying: keys-3.10
rejecting: free-4.0 (conflict: bifunctors==4.1.0.1, free => bifunctors==3.*)
rejecting: free-3.4.2, 3.4.1, 3.4, 3.3.1, 3.3.0.2, 3.3.0.1, 3.3, 3.2, 3.1.1,
3.1, 3.0, 2.2, 2.1.1.1, 2.1.1, 2.1, 2.0.3, 2.0.2, 2.0.1.1, 2.0.1, 2.0,
1.8.0.4, 1.8.0.3, 1.8.0.1, 1.8.0, 0.2.3, 0.2.2, 0.2.1, 0.2.0, 0.1.1, 0.1.0
(conflict: keys => free>=4 && <5)

• A package where all the dependencies are up-to-date returns an empty feed with a 200 OK status code: http://packdeps.haskellers.com/feed/AbortT-mtl
• ..and a package that doesn't exist returns an empty feed with a 200 OK status code: http://packdeps.haskellers.com/feed/not-a-package

Would it be possible for the /feed endpoint to return a 404 status code if the requested package doesn't exist in the same way that (for example) http://packdeps.haskellers.com/reverse/not-a-package does?

This would be helpful for applications consuming the data.

I noticed that my packdeps.haskellers.com-based README badge for my text-show package claimed that text-show has out of date dependencies. In particular, http://packdeps.haskellers.com/feed?needle=text-show claims that it isn't compatible with base-4.10.0.0, but that's certainly not true!

Moreover, packdeps-0.4.4 believes text-show is up to date:

$ packdeps text-show.cabal 
text-show-3.6.2: Can use newest versions of all dependencies

So I'm not sure what's going on here.

The packdeps cli tool seems to duplicate the functionality of cabal outdated, e.g.

$ packdeps -r -p cabal-plan.cabal 
cabal-plan-0.7.2.0: Cannot accept the following packages
bytestring 0.11.0.0

Transitive dependencies:
cabal-plan-0.7.2.0: Cannot accept the following packages
bytestring 0.11.0.0

.../cabal-plan$ cabal outdated
Outdated dependencies:
bytestring >=0.10.0 && <0.11 (latest: 0.11.0.0)

Feature request: Add some text to README clarifying the relationship to cabal outdated and demo some use cases.

(NB: I came here to find a cli version of https://packdeps.haskellers.com/, wanting query reverse dependencies of a package. The packdeps cli tool does not seem to provide the functionality to list reverse deps of a package, though...)

If I search for dhall-to-cabal, I get no results: http://packdeps.haskellers.com/feed?needle=dhall-to-cabal.

The database was last updated recently enough that it should exist. Any idea what's up?

There are new two columns: name of package and version. Can a 3rd column be added that shows the description? For example for yesod add Creation of type-safe, RESTful web applications.

Great package. One problem I have in something I'm working on: We need to provide a package's GenericPackageDescription to obtain dependency information. But... how can I retrieve GenericPackageDescription from the hackage database? I'm looking for something like PackageId -> GenericPackageDescription (or maybe IO Generic...).

I looked in the source of cabal and did not find anything helpful. The only thing that works that I found is an old version of package hackage-db. I can get (sometimes) a GenericPackageDescription, but it's slow (seemingly loading the full db in memory) and buggy (for older versions) or undocumented for newer versions (therefore useless). It seems there is a gap in the process.

Would be nice if the server printed a message "server started on port 3000"

I've been thinking of making a service that would automatically send PRs to subscribed repositories/packages with version bumps coming out of packdeps. (Checking that the subscribed packages still build would, of course, be the responsibility of CI, not of this service.) I could either do this as a separate service, or include it in the current packdeps server - thought I'd ask to see which you'd prefer.

(By the way, packdeps.haskellers.com seems to be down.)

I'm thinking about this because I am looking at https://packdeps.haskellers.com/reverse/hint to try to see which other packages built on top of it, and if one of them could have some specific features that I am looking for at the moment.

Currently I might have to open and read all 55 of them one after the other.

If, however, the table included 'download count in the last 30 days', then I could easily sort that table in my browser with a tampermonkey userscript (written for sorting tables on any site), and go investigate them one by one, starting from most used. Which could allow for 2 more desirable 'early-terminations':

• I either find what I am looking for in the form of a well-used package early on,
• or half-way through I already conclude that even if I would find the desired feature in one of the next packages, hypothetically them having 5 or less downloads in the last month is less than what I would feel justified using.

Same deal with the new(?) 0-3 hackage rating system, which may become even more relevant as more votes are cast. Downloads total could also be interesting to include if it's not too much trouble.

@snoyberg, what do you think about this change? And perhaps if your thoughts start in the direction of this being outside of the scope of packdeps, perhaps you could think of some other, better way with which I could achieve what I am after?

Edit: For this specific hint case I've gone with opening all of them manually and skimming through their descriptions. It surprisingly didn't take too much time in the end, and I could somewhat definitively determine that none of those packages were doing what I was looking for. However, this feature might still make sense for making this a workable avenue to explore packages, especially if there are hundreds of packages to look at.

http://packdeps.haskellers.com/
Something with the VPS issue?

I was curious to know how many packages were depending on the cabal-doctest package, but http://packdeps.haskellers.com/reverse/cabal-doctest claims that there's only one! This is obviously false, though, since a wide variety of packages depend on cabal-doctest, but only in their custom-setup stanzas (here's and example). However, it appears that packdeps-yesod doesn't factor in custom-setup stanzas:

when determining reverse dependency information.

Current packdeps.git does not build with yesod-platform-1.2.
Apart from some needed version bumps for yesod-platform-1.2,
there are some ambiguities for empty and insert in Type.hs.

ghc-7.2 comes w/ a new Cabal version, the following patch fixes compilation w/ ghc-7.2

diff --git a/packdeps.cabal b/packdeps.cabal
index 1e364fe..211cecc 100644
--- a/packdeps.cabal
+++ b/packdeps.cabal
@@ -21,7 +21,7 @@ library
                    , split                     >= 0.1.2.3  && < 0.2
                    , bytestring                >= 0.9      && < 0.10
                    , text                      >= 0.7      && < 0.12
-                   , Cabal                     >= 1.8      && < 1.11
+                   , Cabal                     >= 1.8      && < 1.13
                    , time                      >= 1.1.4    && < 1.3
                    , containers                >= 0.2      && < 0.5
                    , directory                 >= 1.0      && < 1.2

With stack having multipackage repository is a trivial thing. Would greatly improve the workflow, and the web part could depend on Distribution.PackDeps from packdeps package.

I'm happy to do the change.

IMHO it will simplify the overall workflow.

Joachim Breitner advertised on discourse the feature https://packdeps.haskellers.com/feed?needle=Joachim%20Breitner to list one's outdated dependencies.

Would be great to advertise this feature on the packdeps server homepage.

From my local testing of packdeps, it seems no longer to decompress
the downloaded 00-index.tar.gz file. This might be related to the move
to Hackage 2, which seems was accompanied by a change from Apache
to nginx, and at least in the current nginx configuration there is no
Content-Encoding header from Hackage 2 nginx like there was for
Hackage 1 Apache:

old-hackage.haskell.org headers:

HTTP/1.1 200 OK
Date: Sun, 03 Nov 2013 12:26:25 GMT
Server: Apache/2.2.9 (Debian) mod_python/3.3.1 Python/2.5.2
Last-Modified: Wed, 25 Sep 2013 12:26:08 GMT
ETag: "1888009-647d88-4e7345b9a5800"
Accept-Ranges: bytes
Content-Length: 6585736
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: application/x-tar
Content-Encoding: x-gzip

new hackage.haskell.org headers:

HTTP/1.1 200 OK
Server: nginx/1.4.2
Date: Sun, 03 Nov 2013 11:43:29 GMT
Content-Type: application/x-gzip
Transfer-Encoding: chunked
Connection: keep-alive

So http-conduit no longer decompresses the stream saved to "tmp"
and so packdeps fails to load/parse the tar file since it is still conpressed.
It then loops continuously trying to download the index again and again:

$ ./cabal-dev/bin/packdeps Testing
Failed initial load: /tmp/packdeps-cache.bin: openBinaryFile: does not exist (No such file or directory)
Entered loadData
In forever
Received response headers
Finished writing
Received exception: data is not in tar format
In forever
Received response headers
Finished writing
Received exception: data is not in tar format
^C
$

Not sure on the best/correct solution. Do we blame nginx/hackage
or should http-conduit be fixed to address this
or packdeps could just be changed to accept a .tar.gz file?

I suspect this may also be the reason that the data on http://packdeps.haskellers.com seems to be out of date now,
since it is probably not able to parse the compressed index.tar.gz from Hackage 2.

(BTW it seems 00-index.tar.gz now gets redirected on Hackage 2.)

Hi,

packdeps is useful, but still a bit tedious. To hand it to the maintainers on a silver platter, there should be a view (and especially a feed) per maintainer.

I might try to implement this myself eventually, if nobody beats me to it.

Greetings,
Joachim

Well this is a corner case, but in terms of tracking revdeps it would be nice to filter out stack-9.9.9,
(or better ignore deprecated versions from hackage).

The description on hackage says:

The command line tool has an incredibly simple interface: simply pass it a list of cabal files, and it will tell you what dependencies- if any- are restricted.

But when running packdeps */*.cabal it seems to only check the first cabal file listed.

When I look at http://packdeps.haskellers.com/feed?needle=snaplet-sqlite-simple I see that packdeps claims that configurator 0.3.0.0 is not allowed by the snaplet-sqlite-simple 0.4.8 cabal file.

However, this is allowed in the snaplet-sqlite-simple package. The constraint is written as:

    configurator               >= 0.2     && < 0.4,

Is there something in packdeps that cannot deal with < 0.4? I didn't try it this time but I think I've fixed similar problems in the past by rewriting the constraint as:

    configurator               >= 0.2.0.0     && < 0.4.0.0,