search

wokibe / antiprimes

Haskell library for highly composite numbers
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Inaccurate version bounds in .cabal file and other issues #1

Open hvr opened 8 years ago

hvr commented 8 years ago

You uploaded

In my function as a Hackage Trustee I'd like to direct your attention to a few issues I've noticed with that release:

If you have any questions, please feel free to ask!

wokibe commented 8 years ago

Thanks for your mail regarding the flaws of my first upload to hackage. I am a newbie in the Haskell world, anyway since my education as experimental physicist in the late 1960s a have programmed a lot of computers of various sizes with many very different programming languages (assemblers, imperative, scripting,...). Since several weeks I try to learn Haskell. And I struggle with more frustration than having success experiences. There is a lot of documentation, but I have the feeling, there is only few of the from me expected "practical" level or not being outdated.

So I learned, that it is now recommended to use "stack". The stack users guide mentions a "stack haddock", which generates the requested .html documentation somewhere down in the .stack-work directory. And a "stack upload" which sends the sdist of the package to Hackage. I did not find a hint, if it is neceassary to do both in sequence to get the .html files also transferred. I did the upload and got two messages: 1) the transfer was successful and in the next line 2) there was a GPG related error. I found with Google, that there is a --no-signature option, but Hackage refused a second upload with the same release number - which is reasonable. I found my upload on Hackage, but did not find the expected documentation. So I pumped the release to 0.1.0.1 an repeated the upload. I took me some hours to detect an innocent [index] in the middle of the Hackage page of my upload, which was the link to the expected documentation. Perhaps there could be a little "Haddock:" hint there?

The complained contents of synopsis/description in the .cabal file are generated by "stack new simple". I did not see the necessity to modify them, as the "stach build" worked without errors. Perhaps there should be set there something like "TODO: " which generates an error when not changed! (Such a "hint" is used with Rubys "bundler", when supporting a gem generation).

Regarding the wrong version bounds of "base": as being relatively new in the game, I have no idea, what has changed between base-4.7 and base-4.8. The value in the .cabal file was also generated by "stack new" and I did not have any reason to question it. Do you have a tool, which checks such version effects, or did you just guess on your long experiences? (Anyway where can I find, which "base" version was used by "stack build"?

Regarding the missing version bounds of "primes": as it compiled and the hspec tests want fine, I was satisfied. Your mail made me curious which "primes" was used in the "stack build" and I found in .stack-work/installed/x86_64-osx/lts-6.16/7.10.3/flag-cache primes-0.2.1.0-6cf6fc13c1674887d9ef9b97a5d08d52. So perhaps I could use this release 0.2.1.0 as lower and upper bound to indicate which version was tested with this package (a method which is considered as best practice in Rails).

To keep the Hackage clean and usable (which is a very good idea - regarding the piles of scrap collected e.g. in Perl's CPAN or Ruby's Gems) you could perhaps create a "category: sandbox" for newbies like me, where the mechanics of uploads can be trained.

Best regards Wolfgang Kittenberger

On Sun, Sep 11, 2016 at 8:14 PM, Herbert Valerio Riedel < notifications@github.com> wrote:

You uploaded

In my function as a Hackage Trustee https://wiki.haskell.org/Hackage_trustees I'd like to direct your attention to a few issues I've noticed with that release:

-

There does not seem to be any difference between 0.1.0.0 and 0.1.0.1 other than the version increment; was this deliberate?

The synopsis ("antiprimes: Initial project template from stack") and description ("Please see README.md") field content are not sensible and result in poor presentation on Hackage & with tooling such as cabal. See also the documentation for the synopsis/description fields here http://cabal.readthedocs.io/en/latest/developing-packages.html#package-properties

The version bounds stated for base are inaccurate:

base >=4.7 && <5 claims that antiprimes is also compatible with base-4.7, which it demonstrably isn't:

Configuring component lib from antiprimes-0.1.0.1 Preprocessing library antiprimes-0.1.0.1... [1 of 1] Compiling AntiPrimes ( src/AntiPrimes.hs, /tmp/antiprimes-0.1.0.1/dist-newstyle/build/x86_64-linux/ghc-7.8.4/antiprimes-0.1.0.1/build/AntiPrimes.o )

src/AntiPrimes.hs:40:16-23: Not in scope: type constructor or class ‘Foldable’

In other words, base >= 4.8 would be the proper lower bound

-

The (missing) version bounds for primes are inaccurate:

antiprimes claims to be compatible with all versions of primes, which is demonstrably false (e.g. with primes-0.1.1.1):

Building primes-0.2.0.0... Configuring component lib from antiprimes-0.1.0.1 Preprocessing library antiprimes-0.1.0.1... [1 of 1] Compiling AntiPrimes ( src/AntiPrimes.hs, /tmp/antiprimes-0.1.0.1/dist-newstyle/build/x86_64-linux/ghc-7.10.3/antiprimes-0.1.0.1/build/AntiPrimes.o ) [Data.Numbers.Primes changed]

-

All package dependencies lack proper upper bounds: Packages uploaded to Hackage are expected to follow the Haskell Package Version Policy (PVP) http://pvp.haskell.org/ specification, for which it's also essential to specify upper bounds on package dependencies accordingly (i.e. build-depends) for a package to be compliant with the PVP.

If you have any questions, please feel free to ask!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/wokibe/antiprimes/issues/1, or mute the thread https://github.com/notifications/unsubscribe-auth/ABFJbFpqh2BM4DtOCM7B2zkzzhunbUONks5qpET0gaJpZM4J6EM1 .