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

maintenance-depends and a new tool selector for it #10253

Open
geekosaur opened this issue Aug 11, 2024 · 5 comments
Open

maintenance-depends and a new tool selector for it #10253

geekosaur opened this issue Aug 11, 2024 · 5 comments

Comments

@geekosaur
Copy link
Collaborator

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 to cabal 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:

  1. maintenance-depends for tools that are part of development but not of building/testing/etc.
  2. A new selector (currently spitballing tool but I'm not wedded to it) to select these, ghc (replacing the cabal exec ghc hack), and possibly build-tool-depends.
@geekosaur
Copy link
Collaborator Author

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 changelog-d and fourmolu. But I think selectors are by package, so that may be the wrong approach for maintenance tools if we want those in cabal.project instead of package cabal files.

@ulysses4ever
Copy link
Collaborator

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 cabal run them anyway, without touching the package format?

@geekosaur
Copy link
Collaborator Author

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 utils-type package.

@pranaysashank
Copy link

Related issues others have opened over the years: #9230, #10016

@ulysses4ever
Copy link
Collaborator

Should we close this as a dup of #9230? The description here is valuable but at least it's linked from #9230 now...

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

3 participants