stack install package --save to add a dependency to the cabal file

[ajnsit]

It would be nice to have a way for stack to automatically add a package dependency to the cabal file using version bounds (in accordance to some accepted package versioning policy) which accept the current version of the package in the snapshot being used.

NPM provides such a functionality with npm install --save <package> which adds the dependency to the local package.json. So one possible command could be stack install --save <package>.

For example, if I want to use the bound package, and the current version in the snapshot is 1.0.7, then running stack install --save bound in the local package directory would add bound >= 1.0 && < 1.1 to the project cabal file (or something else, as long as it's consistent, and admits v1.0.7). The user is free to manually modify the version range in the cabal file later.

If there are multiple sections in the cabal file where the dependency could be added, then perhaps the user can be prompted for each one with an Add package 'bound >= 1.0 && < 1.1' to the dependency list for this section?.

[mgsloan]

stack upload --pvp-bounds will do this on upload. #1568 is also relevant - it tracks having pvp-bounds use multiple configurations. This allows you to test various points within the version intervals.

The main issue is that there isn't currently a good way to refactor cabal files, as far as I know. Perhaps some heuristics could do a decent job. One reason I'm excited about hpack is that since it generates cabal files, this would be a great time to add in the version constraints - https://github.com/sol/hpack/issues/61 . Alternatively, this could be done as a refactoring on the hpack yaml file, which seems like an easier format to automatically manipulate.

I'm totally in favor of being able to automatically add constraints to cabal files, but someone would need to either write a munger that does this correctly or write a more generic system for automatic changes to cabal files.

[ajnsit]

Hpack is great! It would resolve my use case if stack could automatically add deps to hpack's package.yaml, and then automatically regenerate the cabal file.

I just really dislike having to manually edit configuration files :)

[mgsloan]

I'm the most pumped about just omitting most version constraints from the package.yaml. This will helpfully call out which dependencies are manual constraints that have some particular reason for existing. Adding constraints while generating the cabal file would be consistent with some of hpack's other magic, such as inferring other-modules / exposed-modules / extra-source-files. We can also check in the cabal file, letting us know when the automatically generated constraints change.

[bitemyapp]

Here's another (+1) for this from the IRC channel:

Does stack have a command to add a dependency to my cabal file along with its deps? I am new to Haskell and I am looking for something like npm install --save

…and my personal support. Editing and then building when I could've just told it "add this and build it" would be nicer.

[doppioslash]

+1 it's a common feature in many package manager of other languages, and it was surprising to discover it's not implemented

[ChinaXing]

+1

[leolimasa]

I am new to stack and googled this exact functionality. Coming from the JS world, it is pretty common to use "npm install --save" to install libraries. It does save a lot of time.

[dkoontz]

Big 👍 here as well

[SirensOfTitan]

Would love this as well.

[jerbaroo]

Suggest that what version bounds are added is determined with a flag such as --bounds. And have flag values consistent with --pvp-bounds from stack upload, where a value is one of none, upper, lower, both.

If --bounds is omitted a default value is used, perhaps none since this results in a minimal cabal file edit and allows package version be determined by the snapshot.

[CMCDragonkai]

How would this interact with global-project? Would it save to global-project/stack.yaml or some global-project cabal file?

[decentral1se]

How would this interact with global-project? Would it save to global-project/stack.yaml

Yep - it should be the same behaviour.

[anhmiuhv]

+1

[mgsloan]

If someone wants to implement this, my suggestion would be to first implement the following:

1. A pretty printer for the stack yaml configuration that outputs correct yaml, but in a nice ordering / layout.

2. Add the feature to automate this particular feature, by loading the configuration, modifying it, and pretty printing it. This will get rid of any of the user's comments, etc.

Having this feature, but not as a proper refactoring, might motivate someone to do the full on support for yaml refactoring, which would require a parser that knows about layout and comments, and a exactprint implementation. Not trivial.

Implementing just the proper refactoring would be less work than doing both, but it's a bit tricky, certainly a fair bit of code would need to be written.

[Kurren123]

+1 to this, I'm new and was looking for a stack install servant --save

[balazser]

+1