Skip to content
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

Closed
snoyberg opened this issue Mar 4, 2020 · 3 comments
Closed

Change recommendation: include generated cabal files #5210

snoyberg opened this issue Mar 4, 2020 · 3 comments
Assignees
Labels

Comments

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Mar 4, 2020

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.

@snoyberg snoyberg added this to the P0: Blocking release milestone Mar 4, 2020
@snoyberg snoyberg self-assigned this Mar 4, 2020
@gromakovsky

This comment has been minimized.

Copy link

@gromakovsky gromakovsky commented Mar 5, 2020

One problem with this approach that I encountered is that rebases become more painful. We have a repo with many packages, each one has package.yaml and we store .cabal files in the repo. If someone updates .cabal file(s) in master and you update something different in .cabal files in your branch by updating package.yaml and regenerating them (e. g. you both add a new dependency), you will get unnecessary conflicts because hpack adds a line with a hash.

It's not something critical, I just wanted to warn people about this inconvenience.

@cdornan

This comment has been minimized.

Copy link

@cdornan cdornan commented Mar 7, 2020

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.

snoyberg added a commit to commercialhaskell/stack-templates that referenced this issue Mar 8, 2020
@snoyberg

This comment has been minimized.

Copy link
Contributor Author

@snoyberg snoyberg commented Mar 8, 2020

OK, I'm going to move ahead with this. Thanks for the responses all. Closing as the discussion is done, will be merged to master fairly soon.

@snoyberg snoyberg closed this Mar 8, 2020
snoyberg added a commit to snoyberg/yaml that referenced this issue Mar 8, 2020
snoyberg added a commit to commercialhaskell/pantry that referenced this issue Mar 8, 2020
snoyberg added a commit that referenced this issue Mar 9, 2020
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.
snoyberg added a commit that referenced this issue Mar 9, 2020
This ties off the work fro #5210
snoyberg added a commit that referenced this issue Mar 10, 2020
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.
snoyberg added a commit that referenced this issue Mar 10, 2020
This ties off the work from #5210
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.