-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cases when Hackage information is not updated #1064
Comments
That's what Repology uses:
Given than overall hackage freshness is still >99%, it could be a problem with that index file generation which affects some individual packages.
We don't either, see #838 |
Ok, I would know about this and would look what I can contribute here. Most probably there is a definite canonical Haskell tooling way or tool to directly resolve this information. Maybe I even ask the most knowledgeable person and his club about this on the livestream in a couple of hours. I would report here. |
So. We sorted it out. As testing example here we would use New So looks like they also can further increase version someday. It (01-index.tar.gz) has a new But that does not respect the deprecated versions, we can observe there is Also, |
Also |
Better to do it over official Haskell package management util - the
And you may even share its DB over the node instances in your setup if you want. And so you can update Cabal Hackage DB once in a period you want and use one DB fetch everywhere in your infrastructure.
Deprecated versions are put inside So you can parse this output and receive needed real latest version, this is Also as I mentioned soon there should be the propper support from Hackage API of badge requests, so you would be able to just negotiate a huge quota for repology, and use the API. |
So here we have. If you would need a full list of all versions provided. Then - technically deprecated versions are legitimate, Or if you want the list of only really used versions. You can find a If you want to get the last release version, or last versions on last several release branches - |
Switched to Had to rewrite the parser to allow incremental tarfile in multiple passes. |
I noticed that the project reports wrong Hackage versions, for example for the most famous text formats converter
pandoc
:Repology reports to us that newest
pandoc
on Hackage is2.2.1
, but how can that be when all Haskell ecosystem today releases everything solely through Hackage.Really, on Hackage the latest
pandoc
released is2.9.2.1
2.2.1
version is 2018-05-11, it has been two years of constant development from that point,2.2.1 -> 2.9.2.1
means that by Haskell version policy terms there were 7 major breakage releases in these two years, Haskell packages mostly curated by theirxx.xx.**.**
first and second digits since those mean the API stable releases/branches.I know there is packdeps.haskellers.com and
pacdeps
utility that more canonically determine real last versions. Webservice currently does not respect deprecated versions (like when developers released it as API breakage but then due to no API breackage in real - rolled down the release number into a minor release and deprecated that major release increase). I submitted a report on that, for web service to respect the deprecations.pacdeps
has a--preferred
flag to properly respect the deprecations, deprecations of the major release increases by developers should be respected due to otherwise the service would indicate the old placebo major release, when the development goes and latest releases are in the previous numbers.I do not use
pacdeps
at the moment, so I do not know if it would be useful to your project, but I think most probably.The text was updated successfully, but these errors were encountered: