to throw a couple out there, cabal watch to basically do what ghcid does, and cabal deploy that might be quite ambitious but it would be a killer feature.
5 Likes
By cabal deploy do mean “deploy to Hackage”? Would it be a combination of cabal sdist and cabal upload with appropriate flags?
1 Like
No it’s about deploying an application to a PaaS provider like Heroku, Fly.io or the likes of it
2 Likes
Yes exactly, that’d be dope!
I guess what we’re getting at is to support a more general command, something similar in spirit to npm run <task>, maybe cabal do <task>? then the task can do whatever, I could imagine the tasks to be listed in the cabal.project, perhaps with shake support, so that any shake rule/phony is one of these tasks or, of course, allow the user to specify any IO () as a task.
I wouldn’t do cabal script init, but only because I don’t have the time to make it work.
cabal gui is waiting on an exact parser, but maybe I should go invest the time to make sure all the other features work.
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. 
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.
4 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.