Document Stackage use with remote project config #8083
Conversation
doc/developing-packages.rst
Outdated
|
|
||
| If you use the following ``cabal.project`` file, the packages of the snapshot | ||
| would be constrained to specific versions. The Cabal solver is then liberated | ||
| from determining which versions to use, since it has already been determined |
There was a problem hiding this comment.
Not sure if liberated would be appropiate here. In fact the solver is constrained to use those versions, no?
There was a problem hiding this comment.
Ok, I have removed this part in the new version of the PR which is af9cb08
doc/developing-packages.rst
Outdated
| :: | ||
|
|
||
| packages: . | ||
| import https://www.stackage.org/lts-19.2/cabal.config |
There was a problem hiding this comment.
Not sure if it would be too much info but you could leverage if's to import several lts on ghc version in the same cabal.project
There was a problem hiding this comment.
Let's defer this to a future PR. I think it is nice to have a simple example.
doc/developing-packages.rst
Outdated
| which specifies all of your dependencies' versions. | ||
|
|
||
| A disadvantage of this approach is that consumers who don't use Stackage may | ||
| suffer from the lacking bounds on your package. If published to Hackage, people |
There was a problem hiding this comment.
The usage of lts does not imply necessarily not using bounds in .cabal files. In fact i would recommend use them anyways, in the form ^>=1.0 || ^>=2.1 || ... if you want to support several ghcs/lts's. So you will have the lts and .cabal files checked one against the other and no stackage users will be happy.
I think lts usage should not be seen as a way to avoid set cabal bounds but a way to ensure your build is reproducible. And .cabal bounds would help to accomplish it too
There was a problem hiding this comment.
This discussion as a whole is too gentle. Hackage uploads, by hackage policy, should conform to the pvp, full stop: https://hackage.haskell.org/upload
There was a problem hiding this comment.
The section should simply point out that project files, including imports of other project files, do not get bundled in cabal package tarballs, and so project files are intended for use in local development environments, not for distribution. And it should point out that packages intended for distribution should have pvp compliant version bounds.
doc/developing-packages.rst
Outdated
| :ref:`remote project configuration file<conditionals and imports>`:. | ||
| This frees you from having to determine the acceptable version bounds for your | ||
| dependencies, as described in the previous section. | ||
|
|
There was a problem hiding this comment.
This doesn't free you from anything. It just lets you further constrain things.
There was a problem hiding this comment.
This was removed in the revised PR.
|
Adding a reference to stackage is reasonable, I suppose. However, I don't think that any of this material belongs in the quickstart section -- this is a feature of project files, and project files don't belong in quickstart at all. They're an advanced feature, and quickstart is supposed to describe a simple, minimal workflow. |
|
All right, lots of problems with this it seems, so I'll close |
|
Hey, what about my enthusiastic review? :D I'm sure this can be scavenged (but no pressure). |
This may be a bit too opinionated, and I'd be happy to water it down. But I think it would be nice to explain how to use Stackage, and how it compares.