Please don’t make polluting Hackage even more simple 
Ok nobody here is talking about doing this, let’s keep this discussion on track. This was simply a misunderstanding from Artem. 
I finally wrote a script that does this
5 Likes
Very good!
There is some work happening in Cabal repository w/r/t “listing targets”.
2 Likes
FWIW, stack has this ability since the beginning (Dan Burton implemented it), but as far as I was able to tell, nobody used/uses it. On the other hand it cost nothing to maintain so I guess that’s why we kept it. Small point in its favour.
2 Likes
Yes, stack ide targets was the inspiration for my script.
In my case, I wanted to output names that I can copy-paste into a cabal build command, because often I can’t remember the exact incantation I need to build a subset of a large project.
My script also allows you to include or exclude certain types of components, such as executables or benchmarks, because often I just want to see all the test suites that I can execute.
I chose to write the script in Haskell, using the very handy cabal-plan package, so that I wouldn’t have to embed assumptions about the structure of Cabal files, or which files are actually included in the project with a given set of flags and configuration options.
Ha! That PR is written by the colleague I was working with when we first discovered a pressing need for something like this. Thanks for making me aware of it.
Having it built into cabal-install would be much better, but that PR seems to have gotten stuck in three months of hair-splitting discussion about the right subcommand to use. I’m glad I was able to produce something that works right away, and I don’t have to wait for a stable Cabal release, although I hope the PR gets merged eventually.
2 Likes
This is fantastic! It even works with whole Cabal projects, and whether I am on the top level or deep in the folder tree. No bugs spotted so far. This is a big quality of life improvement for me.
1 Like
I use stack ide targets a lot in a multi-package project to grep and copypaste specific targets without hunting them down through the individual packages.
Dependency License Audit and Automatic In/Exclusion Lists
It would be very useful for cabal to have
- dependency licensing audits that describe the licensing for each of the build targets
- checks that cause the build to fail if dependencies violate: the top package’s license, and/or a specified licensing policy described in the cabal file.
Details
Audit
cabal license audit [--verbose] [--json] [TARGET]
cabal license audit Lists each target and the set of dependency licenses.
`cabal license audit [–verbose] Lists each target and a flattened recursive map of the dependencies and their associated license.
cabal license audit --json Outputs in formatted json or some other formatted text if json is not desirable.
$ cabal license audit
library library-name
BSD-3-Clause
...
executable executable-name
BSD-3-Clause
...
test-suite test-suite-name
BSD-3-Clause
...
benchmark benchmark-name
BSD-3-Clause
...
Builds Failing From License Violations
If a licensing policy is specified and a violation is found, the build should fail with a description of which dependencies are violating the policy.
The flag --ignore-licenses should be added to cabal build so that the license checks are not performed.
Policy Description
There should be an optional field licensing added to the top level and each component that has subfields that allow for inclusion and exclusion patterns.
The below is just an example and there may be a better way to describe the policy
licensing
BSD*
executable executable-name
licensing
! GPL*
I am unsure how the global licensing policy should interact with the target licensing policy. Perhaps, the target policy patterns could be prepended to the global policy patterns and the first match is what is selected.
5 Likes
I’m planning to maybe write an audit tool that has a maintainer blacklist as input, so I can see potentially problematic dep-trees.
3 Likes
Could you list some instances for the need of a maintainer blacklist?
The blacklist seems problematic since it is very easy to change usernames.
A bit difficult given the various vcs, could commits be searched as well for users?
It would be nice to have the tool download a regularly updated list.
I don’t think @hasufell is talking about adversarial maintainers, but just those who are no longer maintaining a large set of packages (that’s what I’d find a blacklist useful for, anyway).
1 Like
To me, open source is about trust.
A library maintainer can delay, break and disrupt my own packages. I try to pick the libraries I depend on mindfully… and that includes maintainer behavior: how they react to bug reports, deal with breaking changes, etc.
These are practical concerns, not “I don’t like them”.
2 Likes
Thanks for the details. It would certainly be interesting to have a public database on this.
Just started working on cabal-bump for automating incrementing the package version for the pull request.
1 Like
I think having something like that public would cause more harm than good and could be seen as an attempt to discredit maintainers.
I see it more about answering the question “do those maintainer’s values align with mine?”. If the answer is no, it might be better to avoid all their packages. And that’s better kept private.
2 Likes
@BebeSparkelSparkel @hasufell the discussion on dep-trees and maintainers is interesting.
For implementation ideas and problems regarding a specific command I would ask you to open a new thread, and let this be for quick pitches on the external command system.
1 Like
I revised the implementation of cabal target following advice from @andreabedini and the PR merged last week. I’m already using it a lot. Here are its unreleased docs.
2 Likes