lint-suite / dev-suite options for *.cabal configurations

[mcandre]

Hi, I am currently using the "test-suite" section of my *.cabal files in order to configure developer dependencies like hlint and shake, so that "cabal install --only-dependencies --enable-tests" can reliably manage these development tools, including the exact versions used for my projects. This is working okay, allowing me decent control over the dev tools in my Haskell projects, and documenting and automating their installation.

However, I would prefer to be able to specify linters and other development tools in a section like but not exactly the same as the "test-suite" section. For one, I personally make a distinction between the lint and test steps of my build workflow, as most people consider stylization as separate from testing.

Second, and more importantly, I don't always have a full "test-suite" configuration for a project, complete with the required type and main-is fields. I have been using dummy values for these regarding Haskell projects that I lint but do not currently test. This awkward situation becomes clearer as people start to actually use my Haskell libraries, as their "cabal install --only-dependencies --enable-tests" invocation would pull in tools like hlint and shake, that are not actually required for testing. Again, these should really go in a "developer-dependencies" section akin to how NPM and Bundler manage dependencies.

What do you think, could we get a new Cabal section like this for non-test, non-executable, non-library, developer dependencies?

[hvr]

Can you maybe show us a more concrete example of such a project?

In the mean time I'll try to answer something that might be related; so if I understand your concern correctly, I have a workaround for this which I use: I don't like to conflate project-config concerns with package-description concerns;

specifically, the $pkg.cabal file should be kept as free as possible from development workflow related concerns -- the $pkg.cabal file's main concern is for software distribution; whereas we have the relatively new cabal.project file which is intended to provide a local project configuration and where you'd ideally setup the project for your current development workflow involving one or more packages. More concretely, you can have additional separate non-distributed $pkg2.cabal packages which can contain what you're currently trying to include in your primary .cabal file.

[jneira]

What do you think, could we get a new Cabal section like this for non-test, non-executable, non-library, developer dependencies?

I think the response was .cabal files are not the best place to put them but cabal.project. And as we had an issue for that (#6952) which was closed in favour of #7865 (see #6952 for the rationale). Thanks!