How to satisfy Hackage uploading Stack-based packages

45 views
Skip to first unread message

sshuck

unread,
Dec 9, 2020, 1:16:16 AM12/9/20
to haskell-stack
Hello fine haskell-stack people,

I am trying to upload my Stack-based library to Hackage, but it's not able to resolve dependencies and thus doesn't build documentation.
Here's some info:
  1. Latest Stackage LTS resolver (16.25)
  2. Cabal file is completely auto-generated
  3. `stack sdist --pvp-bounds both --test-tarball` executes and tests on my computer just fine, both Windows 10 and WSL2 (Ubuntu 20.04)
  4. Uploaded the resulting tarball from .stack-work/ manually via Hackage web UI
Here's the link to the package page, containing further links to Github, the auto-generated PVP ranges, and the build failure logs:  https://hackage.haskell.org/package/pcre2

Any tips on what I'm supposed to do to solve this would be greatly appreciated.
Thanks,
Shlomo

Michael Snoyman

unread,
Dec 9, 2020, 1:22:31 AM12/9/20
to sshuck, haskell-stack
You can see the cabal build error by clicking on the "build log" link on your Hackage page, which goes to https://hackage.haskell.org/package/pcre2-1.0.0/reports/2. Here's the juicy bit:

[__1] rejecting: text-1.2.3.2/installed-1.2.3.2 (conflict: pcre2 =>
text>=1.2.4.0 && <1.3)
[__1] trying: text-1.2.4.0
[__2] next goal: base (dependency of pcre2)
[__2] rejecting: base-4.14.1.0/installed-4.14.1.0 (conflict: text =>
ghc-prim>=0.2 && <0.6, base => ghc-prim==0.6.1/installed-0.6.1)

The PVP bounds added by Stack are putting a lower bound on text of 1.2.4.0. That version of text has an upper bound on ghc-prim of < 0.6. GHC 8.10.2 ships with ghc-prim 0.6. And the Haddock build server only builds with GHC 8.10.2. Your options to fix this are:

* Convince the text package maintainer to relax the upper bounds on ghc-prim so it will build with GHC 8.10.2
* Stop using the --pvp-bounds flag so you don't get the lower bound on text

I no longer recommend the --pvp-bounds flag, specifically because of causing problems like this.

--
You received this message because you are subscribed to the Google Groups "haskell-stack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-stac...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-stack/150cecbe-d4c6-409f-b98a-9b9aa7fe9b09n%40googlegroups.com.

sshuck

unread,
Dec 9, 2020, 10:33:39 AM12/9/20
to haskell-stack
Fantastic, thanks for the quick reply, digging in, and the suggestions.

Just to get over the hump, I did two more releases, the first manually relaxing the text lower bound (failed), and the second removing --pvp-bounds altogether (succeeded).  In the past I've been advised by Hackage curators to set bounds for every dependency for a package I took over maintainership of.  Which in principle I agree with but in practice it's tedious and also hard to know what the actual requirements are.  To illustrate, the candidates upload feature does not do CI, so I can't know if it'll fail, and I can't delete non-building releases when they do fail.

My outstanding questions are:
1. Where is there documented a sensible policy for setting and maintaining bounds that will satisfy mainstream tools and personnel;
2. Do any tools exist that can help automate this;
3. How can I have these bounds committed to source control versus manually tweaking the tarball before upload, and hopefully still use Stack in my project;
4. How can I test Hackage's CI locally to know if my upload will build there?

Thanks again for the assistance.

Michael Snoyman

unread,
Dec 10, 2020, 7:14:14 AM12/10/20
to sshuck, haskell-stack
On Wed, Dec 9, 2020 at 5:33 PM sshuck <steven...@gmail.com> wrote:
Fantastic, thanks for the quick reply, digging in, and the suggestions.

Just to get over the hump, I did two more releases, the first manually relaxing the text lower bound (failed), and the second removing --pvp-bounds altogether (succeeded).  In the past I've been advised by Hackage curators to set bounds for every dependency for a package I took over maintainership of.  Which in principle I agree with but in practice it's tedious and also hard to know what the actual requirements are.  To illustrate, the candidates upload feature does not do CI, so I can't know if it'll fail, and I can't delete non-building releases when they do fail.

My outstanding questions are:
1. Where is there documented a sensible policy for setting and maintaining bounds that will satisfy mainstream tools and personnel;

This is unfortunately more complicated than it should be. The short version of the backstory is: some people want complete compliance with PVP rules. Others think the rules are useless, and don't have a reason to implement them. Personally, I fall almost entirely in the second camp. I tried to find some compromise positions (including the --pvp-bounds flag), but nothing short of full compliance satisfies the PVP side. Ultimately I gave up, and now I just ignore PVP rules.
 
2. Do any tools exist that can help automate this;

I don't think anything beyond --pvp-bounds.
 
3. How can I have these bounds committed to source control versus manually tweaking the tarball before upload, and hopefully still use Stack in my project;

You're free to add the bounds to your cabal file or package.yaml file if you like. Stack will respect the bounds if present, and give you a bounds error if you violate them.

Whether it's worth that effort is up to you. I've decided for myself that it's not worth it.
 
4. How can I test Hackage's CI locally to know if my upload will build there?


Not in any way I'm aware of.
 
Reply all
Reply to author
Forward
0 new messages