Please, respect Preferred versions in the web service - that allows automation

[Anton-Latukha]

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.

[phadej]

There is --preferred flag:

  -p,--preferred           Consider only preferred versions

[Anton-Latukha]

Ok. Sorry for the bad addressing. I would rephrase properly.

Use that by default it in the web service.

Since Cabal ignores (would never pick) those versions of the package:
http://hackage.haskell.org/package/binary/preferred

[phadej]

Cabal will pick them if forced. Those are preferences not constraints.

[Anton-Latukha]

Well, that "forcing" of the Cabal should be deliberate. If people deliberately would arrange constraints to make that the only possible version, and would ignore the changelogs, following the protocol and and respecting the preferred versions.

It is more a system exploit hacking case, that is not proper usage of the Hackage.

Tool should not be concerned with those, but instead, follow the Hackage and Cabal.

I would put it simply.

If to automate things using the web service, or using the RSS feed - the binary | 0.10.0.0 would just explicitly hang there all the time, so it would notify me that I have package update issues, but it is a deprecated version by the binary project themselves, so or maintainers should ignore that notifications in the RSS and the webservice constantly, or the service respect the deprecation by creators of the package.

I not thinking only about me here, but about the community in general - there is more in to gain of respecting preferred versions and hide deprecated by their own creators versions, then to making it look like they are legitimate versions.

And that argument has the argument of the possibility of automation on top of it. It is basically possible to create for example a badge, with a link to your service, on the project page that would report is there are unmet constraints, so every contributor can see the current dependencies state. But if it is in constraints unmet state all the time, because there were deprecated releases - it would now show the real state of dependencies most of the time.

Thank you, I wish the best to everyone.

[phadej]

I was nitpicking on the never word.

I'm also not a maintainer of the webservice, only the cli part.

[Anton-Latukha]

Then I wish the GitHub had an article text discussion thread, like the Wikis, that would allow to some degree the ability to address rephrasing, so some efficient use of a little level of rewriting paradigm that saves the main thread.

Because there is a lot of rephrasing to be done and more detailed explanation requests in the GitHub message threads.