-
Notifications
You must be signed in to change notification settings - Fork 697
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
maintenance-depends
and a new tool
selector for it
#10253
Comments
There are a number of things that need to be ironed out here, the most important of which is that in many cases you may want tools to be per project instead of per package: consider our own use of |
A silly question to those more knowledgeable than I: is it impossible to add this new field to the project file format and teach cabal to |
I think project-level information doesn't support dependencies; cabal considers that package level. It is possible that doing this with cabal as it currently exists would require a |
Describe the feature request
The idea is to support things that are per-project or per-package, but aren't strictly build tools: formatters,
changelog-d
, etc. This would also provide a more principled approach tocabal exec ghc
(see #10196).Additional context
Other build tools, such as npm, already support the concept of dev tools independent of build tools. But the primary reason for this is for code formatters, which in the Haskell ecosystem require you to pin formatter versions. There are currently few ways to deal with multiple projects that require different versions of e.g.
fourmolu
without resorting to external facilities (nix-shell
,direnv
, etc.).This proposal involves two changes:
maintenance-depends
for tools that are part of development but not of building/testing/etc.tool
but I'm not wedded to it) to select these,ghc
(replacing thecabal exec ghc
hack), and possiblybuild-tool-depends
.The text was updated successfully, but these errors were encountered: