New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change recommendation: include generated cabal files #5210
Comments
One problem with this approach that I encountered is that rebases become more painful. We have a repo with many packages, each one has It's not something critical, I just wanted to warn people about this inconvenience. |
I have been getting feedback from non-stack users complaining about repos with no cabal files. From their perspective it is frustrating so I am delighted with this proposal even if it might be a little more inconvenient. N retrospect Cabal files form the basis of the package system so it is better to include them directly. |
OK, I'm going to move ahead with this. Thanks for the responses all. Closing as the discussion is done, will be merged to |
This ties in to the overall goal of #5210. Lock files should no longer include packages without cabal files. We could either remove those from freeze files, or get rid of freeze files entirely. Since freeze files are already on their way out, may as well just cut them off entirely now.
This ties in to the overall goal of #5210. Lock files should no longer include packages without cabal files. We could either remove those from freeze files, or get rid of freeze files entirely. Since freeze files are already on their way out, may as well just cut them off entirely now.
Agreeing with gromakovsky that this can very often cause conflicts and pain when merging/cherry-picking/switching branches/trying different stack/hpack versions. I think it's worth changing hpack to fix this - if you agree, consider helping sol/hpack#380. |
Hi! Let me just describe one failure mode collateral from this change. Hopefully, it'll make searching for it easier and speed up resolutions. No response required. First, the error message:
Now the cause. In my case, local-development Stack v2.3.1 has produced unintended change to @@ -154,9 +140,6 @@ packages:
- completed:
size: 294200
url: https://github.com/private-company/vendor-fork-redacted/archive/fcbaf261368b7f63708351fb1b04eb7f5f0793a3.tar.gz
- cabal-file:
- size: 4079
- sha256: a24d964776e360d0545500c8b28ec254aa323fdf28fa55692a282a25b6ac652c
name: vendor-fork-redacted
version: 0.9.1
sha256: 54974f6f9851376292cb6f081eef2cd907396899a04af5776da2d2cc45e80fc6 Reverting this unintended change fixes the error (as well as updating Stack on CI). The error reporting could perhaps be better; but this behavior change is well-documented on the ChangeLog. Hope that helps |
This is now the recommended way by stack: - commercialhaskell/stack#5210 - https://www.fpcomplete.com/blog/storing-generated-cabal-files/
@snoyberg I don't think that this proposal works with Ideally, the |
Yeah in the world where you commit .cabal files I'm not sure I see the utility of On a side note, reading up on this very proposal (that I was not aware of):
In my view that's an issue of individual workflow, not projects or ecosystem as a whole. Just like using chains of |
Should this issue be revisited? The decision was made allowing only 4 days and with only a handful of votes - I'm not convinced that this represents a majority of users. The blogpost says more about implementation details that I'm relunctant to dive deep (my apologies if any of my concerns below has been addressed in the blogpost), but from user's point of view, why I have to suffer this deprecation notice which is not even my fault? If reproducibility is the concern, I don't see In addition, the reason why I choose A potential workaround I can think of for now is to have both main project and library reside under the same repo, this might not be applicable to all use cases, unfortunately. |
Because you're breaking your repository for every cabal user: https://cabal.readthedocs.io/en/latest/cabal-package.html?highlight=source-package-repository#source-repositories This only works under cabal if your cabal file is checked into git. |
@Hasufel It is my choice that the repo is managed by Stack, not Cabal. If it's a release meant to be general Haskell package, sure I'll fix it. But I'm stressing that I'd avoid checking in a generated file unless absolutely necessary (I think "source" as "source of truth" rather than "source from the Cabal point of view") - I don't think being compatible with Cabal (again, for the repo) fits that category. |
@Javran I'm in the same boat with you in regards to committing generated files coming to be a must. That's seriously not cool. My diff reading time is limited — just as anyone else's. However, let me express a friendly skepsis: reverting the change of Official Recommendation (with associated counter-deprecations? how would that even...) anytime soon — will spawn a mess an order of magnitude worse. Than either of the two original options, both bad in their own ways: violating DRY and fostering bloat VS breaking naive non-Stack usage of the package.¹ Reverting will spawn a mess, simply due to confusion at scale. One doesn't simply undo a deprecation which has only recently started. Just take a look at how often this issue (which is linked directly in Stack's deprecation message) has been referenced from within GitHub this year. People are still discovering this change. The Stack #5210 deprecation is still in progress. Since everyone discovers the deprecation at their own pace, and on longish timescales (months, years) — it won't be wise for Stack to take a sudden 180° change of direction in the middle of it. Doesn't even matter how great the technical arguments are. What I found to work "well enough" in practice. Add a GitHub Linguist annotation in
This blog shows the effect; you get diffs which auto-hide on GitHub. Won't help with rebase conflicts however. ¹ I say "naive" because... what's there preventing Cabal users from calling |
@ulidtko Thanks for the suggestion, although I check diffs mostly though editor plugins or CLIs, which GitHub Linguist feature won't solve. (EDIT: I've just checked that adding I fully understand that reverting such decisions will cause huge disruption one way or another. Would it be practical to settle with status quo (i.e. not removing hpack support in the future) and an option to supress this warning with the acknowledgment that repo won't be Cabal-compatible? Another path could be some hooking mechanism to call hpack after repo is checked out, or customizing |
Quick update: I see looking into customizing
|
Importing libraries without cabal files are now depricated See: commercialhaskell/stack#5210
* Added .cabal files to repo See: https://docs.haskellstack.org/en/stable/stack_yaml_vs_cabal_package_file/#should-i-check-in-generated-cabal-files commercialhaskell/stack#5210 * Fix haddock build
For details of the proposal, see the blog post: https://tech.fpcomplete.com/blog/storing-generated-cabal-files
If you are in favor of this change, please press thumbs up below. If you are opposed, please press thumbs down. Of course, feel free to include additional comments below.
The text was updated successfully, but these errors were encountered: