I would probably use it to get cabal b and cabal r as in cargo
1 Like
I can imagine that b is an alias for build, what about r?
1 Like
cargo r is short for cargo run. Saves 2 characters, but for whatever reason it really feels like it makes an enormous difference. Full list of aliases from cargo --help:
Some common cargo commands are (see all commands with --list):
build, b Compile the current package
check, c Analyze the current package and report errors, but don't build object files
clean Remove the target directory
doc, d Build this package's and its dependencies' documentation
new Create a new cargo package
init Create a new cargo package in an existing directory
add Add dependencies to a manifest file
remove Remove dependencies from a manifest file
run, r Run a binary or example of the local package
test, t Run the tests
bench Run the benchmarks
update Update dependencies listed in Cargo.lock
search Search registry for crates
publish Package and upload this package to the registry
install Install a Rust binary. Default location is $HOME/.cargo/bin
uninstall Uninstall a Rust binary
2 Likes
I always have
alias cb='cabal build'
alias cr='cabal repl'
5 Likes
Another usecase I just discovered is generating ci workflow files (like Github’s .github/workflows/ci.yml) from cabal files. For example, the workflow for GitHub - haskell-CI/haskell-ci: Scripts and instructions for using CI services (e.g. Travis CI or Appveyor) with multiple GHC configurations currently consists in invoking haskell-ci with the name of the cabal file, but if cabal can provide the metadata from the cabal file itself, then cabal ci would also be a nice tool for managing CI workflows.
2 Likes
Perhaps we could also have a cabal doctests command?
11 Likes
Keep 'em coming, it’s very interesting!
1 Like
I would definitely love to see cabal add <dependency> and possibly even cabal remove <dependency>.
I remember when I first started with Haskell, it was very much a shock that I had to enter dependencies in the cabal file manually; esp coming from the world of nuget and npm and all of that. It really raised the bar for entry as a newcomer, and reading through the cabal manual was intimidating trying to figure out how it works.
This would go a long way towards fostering adoption of Haskell I think
10 Likes
cabal stack ... /ducks
6 Likes
Of course once you have cabal add <dependency> you’ll want cabal expand-bounds [--lower] [--upper] [--test] <dependency>.
1 Like
Let me understand, where would you want to add that dependency? Since v2, cabal-install is mostly project based, and a project can contain many packages. Any (or most) project configuration can be added with cabal configure; but we are a bit stuck at modifying cabal files.
I would say maybe something like cabal add <dependency> <target-package> would suffice. If there’s only one package, just send it there by default.
I dont really know what cabal expand-bounds would do 
… But I don’t know much about cabal files besides how to add dependencies, expose modules, and I just recently learned how to set default language extensions 
3 Likes
Well, Cabal has a notion of targets, such as some-package:exe:some-executable. (Even though it is not communicated to the users as clearly as I should wish — for example, there is no way to list all available targets in the current project.) So, there is already a syntax for telling Cabal where you want to add that dependency.
The hard problem is to get an exact parser-printer pair for Cabal — as I understand, Emily @emilypi championed this project a year ago or so but it eventually stalled. And without an exact parser-printer pair we cannot programmatically add or remove anything.
1 Like
The exact-print parser is coming. 
12 Likes
As I understand (or project) your idea for the cabal add command, it would be as simple as possible so the beginners with trivial projects and packages don’t need to go into the weeds of what’s possible. Another requirement would be that the resulting bounds are PVP-compliant. The intersection of these two requirements means that the command cabal add my-new-dependency would just add something like , my-new-dependency ^>= X.Y.Z where X.Y.Z is the latest version of the dependency in Hackage index. The command should probably also verify that the bounds of my-new-dependency-X.Y.Z bounds are compatible with the bounds of all the existing dependencies, but that’s as far as I’d have it go.
That’s for beginners. Once those beginners gain some experience, they’ll notice that the automatically-added dependency bounds are too restrictive. Expanding those bounds is a far more demanding task with more knobs and a different user base. That’s why I’m suggesting it should be a separate Cabal command rather than a set of options on cabal add.
1 Like
Ah I see, yea that makes sense, and I agree. The cabal add command is for the beginners, or for people who just wanna go fast; It shouldn’t have to do anything more than just pick the latest version (or the latest version that works). It would be cool if it was capable of figuring out the widest possible version bounds, but that’s probably outside the scope of such a tool
1 Like
Slowed, not stalled - it needed a person who wanted to see it through to the end and sadly, I became busy with life. Leave it to @Kleidukos and the more active team members and we’ll have one soon enough.
Heyo!
Our HSoC participant @VeryMilkyJoe is working on a POC for Feature Request: Add current file to Cabal (exposed/other) modules · Issue #3595 · haskell/haskell-language-server · GitHub. In the context of that work, a third-party Cabal parser is currently being written, that hopes to become an exact printer in the future. We don’t want to promise too much at this point, though.
Stay tuned for updates and the next HLS release
5 Likes
Also remove-bounds!
Currently I have some hacky shell scripts in ghc-rpm-macros for packaging:
- cabal-tweak-dep-ver
- cabal-tweak-drop-dep
- cabal-tweak-flag
etc
5 Likes