Independent goals in extra-packages

[fgaz]

Currently extra-packages are solved all together, and together with all other packages in the project too. This restriction is artificial and it can cause the solved versions to be older than actually needed. See #6952 (comment) for more details

[michaelpj]

This seems like a complaint that extra-packages does not function like extra-executables. I think we're already stretching the behaviour of extra-packages to use it in this way, if we want something that provides some extra executables to install we should just add a new thing for it.

[gbaz]

@michaelpj I disagree. In general, there's no reason extra-packages need to be solved together, so its correct we shouldn't be doing it. Once that's fixed, then it will just so happen that it will suffice to provide executables in the desired way. I.e. if we fix something that should be fixed anyway, then there will be no need for a new thing.

[Mikolaj]

@michaelpj: what's the drawback? Is it that potentially we'd build new versions of the same deps instead of using the same as for the main package? Any realistic and disastrous scenario for that? Anything else?

[michaelpj]

Hmm, I think maybe I just have a different idea about what the "build-plan policy" is. I can think of at least two:

• Only things which are definitely linked into the main build are built with a consistent build plan, everything else gets an independent build plan.
• Everything gets a consistent build plan by default, unless we absolutely know it can't be linked into anything (i.e. executables).

I think I intuitively want the latter policy, although I don't have a great justification. The best thing I can think of is that something like extra-packages could have uses that require linking into the main build. For example: we could make it so that extra-packages were included in the global package db when using cabal repl, so they could be imported for ad-hoc usage without adding them to the cabal file. Nice for experimenting with generating values with quickcheck, say. In that case you really would want them to be built with a consistent build plan!

So I guess we don't really have a clear definition of what extra-packages is for, so I'm running some heuristic like "it's a 'package-like' thing, rather than an 'executable-like' thing, so our users might assume it can be linked in" or something.

[fgaz]

As additional context, the original motivation for extra-packages is indeed to include extra libraries consistent with the build plan: #3737 (comment) . I guess we do need to distinguish the two cases after all

[mcandre]

Presently, Haskell users have to manually manage dev dependencies. Which leads to many problems: Undocumented build steps, repeating code multiple times, writing provisioning scripts to manage dev dependencies, growing the tech stack to include sh/Python/Ansible/Ruby/Chef/Puppet/batsh, and worse.

To be clear, my desire is for Cabal to be able to pin and install developer tools like happy, in a convenient section of the Cabal configuration, similar to how RubyGems and NPM behave.

If this feature helps to implement a dev dependency section in Cabal configuration, more power to it.

[gbaz]

Cabal can pin and install dev tools like happy, via the build-tools-depends field of cabal files themselves. This ticket is just about extra-packages in cabal.project files.

[cumber]

FWIW, I have been using extra-packages for adding in little things like raw-strings-qq` to have available as extra libraries for use when interactively testing in the REPL.

Presumably if the contents of extra-packages were solved independently of the main build that wouldn't work, and they wouldn't be importable in a REPL session that has also loaded my main code and its dependencies?

[fgaz]

I guess we should consider closing this, possibly in favor of a new ticket about extra-executables