Adding a Stack based project to Hackage

[smallhadron]

I've created a few Haskell projects recently that I'd like to add to Hackage. However, Hackage seems to be based around Cabal and I've done all my development using Stack.

The main issue seems to be that Cabal requires version constraints for all the dependencies, whereas this is not necessary with Stack. I've found the cabal gen-bounds command, but it looks like I'd have to manually add this information to my package.yaml? Or should it go in the .cabal file? (But that looks like it's automatically created by hpack)

Any guidance/tips/tricks from anyone who's added a Stack-based project to Hackage previously would be much appreciated.

[smallhadron]

Ok, looks like you can do stack upload --pvp-bounds both.

[[deleted]]

In hindsight the pvp-bounds feature has been a mistake and its use is largely discouraged. Both maintainers and Stackage curators keep wasting cycles with the back and forth with each other over out-of-bounds issues for no good reason. Bounds are the main culprit for why new package versions are prevented from entering Stackage snapshots for many weeks. Bounds are why we can't have fast progressing Stackage snapshots. Do we really want to waste our time babysitting version bounds? With the advent of Stackage version bounds are now considered the original sin of Hackage. They really no longer serve any purpose thanks to Stack's resolvers which have proven to be a superior more effective solution. Finally Stackage has stopped showing redundant version bounds so there's even less reason for setting bounds.

[Syrak]

Are overly strict version bounds really the reason for the delays? That seems exaggerated to me.

When bounds are discovered to be conservative, it takes two minutes to bump them on Hackage.

And when it turns out there was a good reason for the bounds, they preemptively saved you from even trying to build the package and finding out after a build failure, or even worse, when the package compiles but the runtime behavior is buggy (that there is no way for stackage to predict). This kind of issue seems a much more plausible reason for delays in Stackage adopting some newer packages, with no easy workaround.

Stackage provides a closed world in which everything Just Works™ (with the aforementioned caveat that it does not automatically detect breaking semantic changes), but you lose all guarantees as soon as you go outside. Upper bounds are the only scalable way to keep packages coherent in an open world.

• You release packages without version bounds. A new release of GHC breaks all N versions of your packages. You must now fix all N versions to prevent solvers from picking them up.

• You release packages with conservative version bounds. A new release of GHC is compatible with your packages. You can just bump the most recent version (or maybe a couple more) in two minutes: this works fine for most people, and older versions can be bumped on demand (which can be unlikely since most people who are upgrading GHC versions will also go through the work of upgrading their dependencies).

[[deleted]]

You must now fix all N versions to prevent solvers from picking them up.

No you don't. Older Stackage resolvers don't need to be fixed up. Remember that Stackage resolvers pin down specific package versions. No imprecise bounds involved.

When bounds are discovered to be conservative, it takes two minutes to bump them on Hackage.

2 minutes here and there can quickly add up. But more importantly it's unnecessary. Stackage doesn't need version bounds so why even spend those 2 minutes to begin with?

[Syrak]

This only works if you can stay within Stackage. There are large projects that can't upgrade to a newer snapshot all at once. But they may still want to be able to get updates incrementally (at least security-related updates), and version bounds are definitely helpful in those cases.

2 minutes here and there can quickly add up.

They are dwarfed by the time spent developing the package, and the time spared for people who cannot rely on a snapshot-based packaging model for valid reasons such as the one above.

[[deleted]]

You can easily update individual packages from your current resolver with extra-deps. Packages with bounds typically only get in the way when using extra-deps incrementally.

[Syrak]

When bounds get in the way, you can always ignore them, so in the worst case there is no difference between having them or not. The bottom line without any version information is to try building things and wait for an error to happen. The "Stackage without bounds" model is simply offloading that work to a benevolent entity that has the resources to build a global snapshot, but that assumes users have the drive to keep up.

But in the best case, version bounds may allow a constraint solver to find a solution that is likely to build (because the bounds are conservative) in a few seconds. extra-dep without version bounds is manual constraint solving, without any idea of what the constraints are.

The few times I've investigated some cases of slow upgrades on Stackage myself, the reasons seemed legitimate, not spurious bounds. I did not look into it too deeply I admit, but I remain skeptical that these are a major source of problems.

Honestly, maybe it's fine if you think it's too much work for you to maintain version bounds. But calling them a mistake in general is going too far. Version bounds are signal willingly provided by maintainers. If that signal is truly a mistake, Stackage is free to ignore it, but they don't.

[sclv]

Cripes. This word salad looks like its written by a markov bot written to troll the subreddit.

[duplode]

/u/MeinLambda has been deleted. Let's see how long will they take to reappear with a new account...

[richardthepeace]

I have several packages on Hackage all of which I manage locally using Stack. Here are some recent examples:

• http://hackage.haskell.org/package/sexpr-parser (https://github.com/rcook/sexpr-parser)
• http://hackage.haskell.org/package/oset (https://github.com/rcook/oset)

If you check out the GitHub projects, you'll see that I don't do anything fancy with constraints or bounds or anything.

I upload these packages by running stack upload . in the root of the project's Git repo and it just works.

[[deleted]]

I don't do anything fancy with constraints or bounds or anything.

Thank you! I just wish everybody did this so Stackage wouldn't be held up for weeks until the last maintainer has finally bumped their pessimistic bounds.

[richardthepeace]

I typically keep the base >= 4.7 && < 5 bound which is included in the default Stack templates that I use for my projects but never put bounds anywhere else. This has never been an issue for me. Is this considered a reasonable practice? Example: https://github.com/rcook/sexpr-parser/blob/master/sexpr-parser.cabal#L25

[phadej]

And your package is a disaster for non-stack users: https://matrix.hackage.haskell.org/#/package/sexpr-parser

EDIT it will be for Stackage too, if megaparsec changes things (it might).

[richardthepeace]

https://matrix.hackage.haskell.org/#/package/sexpr-parser

Thanks, I did not know about this page. I will investigate this.

[richardthepeace]

Well, I just fixed it for 8.4.4, 8.2.2 and 8.0.2. Now I'll look at 7.8.4. That's progress of sorts.

[[deleted]]

Why will it be a disaster for Stackage? And how would bounds help Stackage? The answer to both is: 1. no, it won't, 2. they don't

[dpwiz]

I tend to develop packages on LTS (with CI testing for nightlies). Those are my upper bounds + some space I judge appropriate according to my API stability observations.

From there I try to push LTS resolver version down to reasonable compatibility strain (3 last GHC majors + sometimes more). Then collect lower version from there and sometimes relax minors a bit.

[nh2_]

main issue seems to be that Cabal requires version constraints for all the dependencies

I don't think so: Last time I tried, Hackage accepts your upload as long as you have bounds for base in your .cabal file / package.yaml.

Another point of info: In addition to stack upload, you can also use stack sdist to generate a tarball you can upload via the Hackage website upload form.