You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Change recommendation: include generated cabal files #5210
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.
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.
Reacted by Michael Snoyman, Андреев Кирилл, Tom Sydney Kerckhove, Konstantin Ivanov, Boris Buliga and Andreas Källberg
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.
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.
Activity
gromakovsky commentedon 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.yamland we store.cabalfiles in the repo. If someone updates.cabalfile(s) in master and you update something different in.cabalfiles in your branch by updatingpackage.yamland 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 commentedon 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.
Don't ignore cabal files commercialhaskell/stack#5210
snoyberg commentedon 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
masterfairly soon.Check in generated cabal files (closes #176)
Warn on missing cabal files commercialhaskell/stack#5210
Remove the freeze command
Lock files skip packages without cabal files
Remove the freeze command
Lock files skip packages without cabal files
simonmichael commentedon Apr 15, 2020
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.
40 remaining items
[Housekeeping] Should have committed this before but didn't get aroun…
Include generated Cabal file
Include generated Cabal file
Checked in generated Cabal file
Checked in generated Cabal file
check in cabal file: commercialhaskell/stack#5210
Added .cabal file to repository in line with commercialhaskell/stack#…
Added `peano.cabal`
Add cabal file, as per commercialhaskell/stack#5210
Add cabal file, as per commercialhaskell/stack#5210
add cabal file to follow newer stack conventions
Check in generated Cabal file
Check in generated Cabal file
Added .cabal files to repo (#123)
Haddock fix (#124)