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

Optionally exposed modules / APIs should be banned #778

Open
bos opened this issue May 24, 2012 · 0 comments
Open

Optionally exposed modules / APIs should be banned #778

bos opened this issue May 24, 2012 · 0 comments

Comments

@bos
Copy link
Contributor

bos commented May 24, 2012

(Imported from Trac #788, reported by @dcoutts on 2011-01-11)

It is a deliberate decision that packages cannot depend on package + flag combinations, only on packages. The point is that flags are not supposed to change the API of a package.

This needs to be enforced.

Consider a real example (from Chart package: http://hackage.haskell.org/packages/archive/Chart/0.14/Chart.cabal)

  if flag(gtk)
    build-depends: gtk >= 0.9.11
    exposed-modules: Graphics.Rendering.Chart.Gtk
The criterion package depends on Chart and imports Graphics.Rendering.Chart.Gtk meaning that it breaks if you build Chart with the gtk flag turned off.

The solution is that Chart should be prevented from conditionally exposing modules. We should add a QA check that looks for exposed modules that are conditional on a flag. It is annoying but somewhat less bad for modules to change between platforms.

Should it be a hard failure or just a warning?

@ttuegel ttuegel added this to the Cabal-1.24 milestone Apr 23, 2015
@23Skidoo 23Skidoo modified the milestones: Cabal 1.24, Cabal 1.26 Feb 21, 2016
@ezyang ezyang modified the milestone: Cabal 2.0 Sep 6, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants