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
Adding bounds to library with common stanza results in malformed cabal file #26
@@ -56,6 +56,8 @@ common base
other-modules: Paths_ede
library
+ build-depends: aeson <1.6+
import: base
hs-source-dirs: lib
exposed-modules:
If I try to push this revision, the response is:
Warning: ede-0.3.2.0.cabal:61:3: Unknown field: "import"
Pushing "ede-0.3.2.0.cabal" (ede-0.3.2.0~0) [review-mode] ...
Hackage response was (after 0.622 secs):
================================================================================
Errors:
Cannot remove existing library dependency on 'base' in library component
================================================================================
cabal check reveals:
Warning: These warnings may cause trouble when distributing the package:
Warning: ede.cabal:61:3: Unknown field: import. Common stanza imports should
be at the top of the enclosing section
Warning: Hackage would reject this package.
it is questionable for a declarative language that cabal aims to be to demand a certain ordering of the fields. A reason to demand import to be at the top would be that it brings identifiers into scope that are used subsequently. But is this the case for a stanza import?
The way .cabal file works (due decisions done long time ago)
common foo
something: foo
if flag(foo-flag)
something: foo1
else
something: foo2
library
header: headerVal
if os(windows)
something: windows
import: common
footer: footerVal
if impl(ghc)
something: ghc
would desugar into
library
header: headerVal
if os(windows)
something: windows
something: foo
if flag(foo-flag)
something: foo1
else
something: foo2
footer: footerVal
if impl(ghc)
something: ghc
and interpret as if it were
library
header: headerVal
something: foo
footer: footerVal
if os(windows)
something: windows
if flag(foo-flag)
something: foo1
else
something: foo2
if impl(ghc)
something: ghc
because conditionals are pushed back.
That would be fine if all fields contents were commutative (like build-depends),
but buildable isn't, for example, the last one wins.
Thus to avoid any confusion imports have to come first.
That was also a conservative change, it can be relaxed later.
It would be better to "fix" the push-back of conditionals first though.
That said, future relaxations won't help hackage-cli, as older spec cabal files still have to be dealt with.
I don’t want it to look as a shameless plug, but how do we feel about making hackage-cli to use cabal-add API instead of manual updates? cabal-add is almost two years old now and I have not received any complaints about how it works.
I wouldn't object a reimplementation of the add-bound command.
Personally, I stopped using it, I am using wgrep in Emacs to do bulk-editing of cabal files, with much better control over the result than with add-bound.
Activity
andreasabel commentedon Oct 12, 2021
cabal checksays:I'd say this is also an upstream problem;
it is questionable for a declarative language that
cabalaims to be to demand a certain ordering of the fields. A reason to demandimportto be at the top would be that it brings identifiers into scope that are used subsequently. But is this the case for a stanza import?sjakobi commentedon Oct 12, 2021
I agree that it is a surprising constraint. I have no idea about the reasons though.
phadej commentedon Oct 12, 2021
The way
.cabalfile works (due decisions done long time ago)would desugar into
and interpret as if it were
because conditionals are pushed back.
That would be fine if all fields contents were commutative (like
build-depends),but
buildableisn't, for example, the last one wins.Thus to avoid any confusion imports have to come first.
That was also a conservative change, it can be relaxed later.
It would be better to "fix" the push-back of conditionals first though.
That said, future relaxations won't help
hackage-cli, as older spec cabal files still have to be dealt with.sjakobi commentedon Oct 12, 2021
To fix the issue, I think we can simply tweak the existing logic so the additional
build-dependsare inserted after anyimports.Here's the
add-boundimplementation:hackage-cli/src/Main.hs
Lines 780 to 822 in fbf1967
…and the function that finds the insertion position:
hackage-cli/src/Main.hs
Lines 441 to 449 in fbf1967
Bodigrim commentedon Oct 20, 2023
I've developed https://github.com/Bodigrim/cabal-add, capable to insert dependencies even in the presense of common stanzas.
andreasabel commentedon Oct 21, 2023
@Bodigrim Kudos! I'll try it out next time I need to make revisions...
Bodigrim commentedon Aug 30, 2025
I don’t want it to look as a shameless plug, but how do we feel about making
hackage-clito usecabal-addAPI instead of manual updates?cabal-addis almost two years old now and I have not received any complaints about how it works.andreasabel commentedon Aug 31, 2025
I wouldn't object a reimplementation of the
add-boundcommand.Personally, I stopped using it, I am using
wgrepin Emacs to do bulk-editing of cabal files, with much better control over the result than withadd-bound.andreasabel commentedon Aug 23, 2026
Fixed in 0.3.0.0.
sjakobi commentedon Aug 23, 2026
Thank you, @Bodigrim and @andreasabel! :)