snoyberg / packdeps Goto Github PK
View Code? Open in Web Editor NEWWeb app to track lagging package dependencies.
Home Page: http://packdeps.haskellers.com/
Web app to track lagging package dependencies.
Home Page: http://packdeps.haskellers.com/
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)
200 OK
status code: http://packdeps.haskellers.com/feed/AbortT-mtl200 OK
status code: http://packdeps.haskellers.com/feed/not-a-packageWould 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':
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:
packdeps/packdeps-yesod/src/Distribution/PackDeps.hs
Lines 190 to 195 in 27d95d2
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,
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.