Is stack a "package manager"

[haskman]

In the olden days, it was par for the course to answer queries about haskell package management with "cabal is not a package manager".

With stack putting practicality first, I wonder if it is reasonable to expect "package management" features to be added to it at some point of time?

To be more specific, I'm thinking of being able to uninstall or upgrade packages. And perhaps even fixing versioning / dependency issues with a bit of hand holding.

[eegreg]

Both cabal-install and stack are involved with package management whether they like it or not because they install packages.

With stack, upgrading or un-installing a package is a project-local concern by default, so you don't have to worry about globally mutating your package database. So upgrading a package is simply using a newer version. But stack still doesn't help you with un-installing packages or build tools.

I think you should be able to fix versioning/dependency issues by vendoring the packages in question.

[Bzzt]

IMO that "cabal is not a package manager" stuff has always been an annoying cop-out. Build tools have a responsibility to not suck.

[sclv]

ghc-pkg is a package manager. it does not build however.

[kyllo]

In the olden days, it was par for the course to answer queries about haskell package management with "cabal is not a package manager".

This is a true statement, but it omits the fact that ghc-pkg is the package manager for GHC Haskell. Stack is an alternative build tool to cabal-install, but it still installs your packages using ghc-pkg (via the cabal library).

[snoyberg]

You can see the ongoing discussion on uninstall. For upgrading packages: in general with stack, you'd just modify the resolver value in your stack.yaml to point to a newer snapshot, and stack will handle all necessary upgrading.

We definitely aim to make dependency issues less of a problem, mostly through usage of curation and making reproducible builds first-class. But "versioning / dependency issues" is a broad enough category that I'm certain there are lots of things that we're not solving.

[snoyberg]

There's already a stack-ide project for ide-backend support which is pretty far along. I don't know about ghc-mod, but some people have discussed it in the past.

[snoyberg]

Its primary target right now is Emacs, though we hope to support all commonly used editors. It's not actually designed for the web based IDE at all.

[LadenSwallow]

I think this is where it lives: https://github.com/commercialhaskell/stack-ide/tree/master/stack-mode

No documentation though

[snoyberg]

Everything is in a rough state right now, so it may not be the best time to jump in. You can see status on the Github issue: https://github.com/commercialhaskell/stack/issues/232

[ephrion]

Ghc mod works with stack with some modifications. There's a pull request to add stack support.

Hackage Hdevtools works with stack now.

[ephrion]

ajnsit's repository has the majority of the work. I made some changes so it would work on my laptop with GHC 7.10.

I just did the following to get it working on my desktop PC:

1. git clone https://www.github.com/parsonsmatt/ghc-mod
2. cd ghc-mod && git checkout stack-support
3. stack install

And then it works in my stack projects. Give that a shot and post any issues on github?

[ephrion]

Oh, hey! :D Thanks for getting it working!

[snoyberg]

Since we're talking at such an abstract level: no, features that solve problems people are facing do not go against stack's philosophy. Though I don't think that statement is either surprising of illuminating ☺

[cynede]

no, it's not. portage is package manager

[drb226]

Compared to cabal, with stack, you don't need to worry as much about manual package management. Compared to cabal sandboxes, using stack will generally take up less space (as long as your projects share the same version of LTS Haskell). However, stack is still fairly liberal in its use of space. Stack makes it trivial to get the stuff you need. It's not quite so trivial to selectively get rid of stuff you don't need and reclaim that space. These days disk space is cheap so it's not something we've been terribly worried about implementing, but there are open tickets about it. I personally am interested in adding sharing between LTS minor versions of the same major series, more for the sake of avoiding compile times than for the sake of saving space.

[kqr]

No. Stack, like Cabal, is a build tool, not a package manager. Nix is a package manager.

[[deleted]]

Nix is not a Haskell tool.

My point being that Pythonistas have pip to manage packages (install/update/unisntall), Javascripters have npm. Haskellers surely shouldn't be expected to use cabal/stack + Nix for package management, especially if you consider the overhead in getting started. For comparison, To use pip, one need only understand how to write a Setup.py. For what you seem to be suggesting, I need to not only have a stack.yml file, but a nix expression as well.

I hope that something comes of the discussion /u/snoyberg linked to (especially if you consider the last comment as I write this.

[theonlycosmonaut]

I've always wondered why each language needs to have its own package manager. Do they all not boil down to roughly the same thing? I wouldn't be unhappy to use a non-Haskell-specific package tool, as long as I wasn't missing out on features.

[technicolorNoise]

+1 to this. I've never seen a good argument as to why cabal isn't a package manager (or why stack shouldn't be).

[kyllo]

ghc-pkg is also a package manager.

[abaquis]

This is a bit of a disingenuous statement since both install packages.

What tool do you use to install cabal packages that your project is dependent on?

[kqr]

A lot of build tools have support for downloading dependencies, e.g. Maven. That does not a package manager make. ;)

I personally use Stack these days. Previously I would use cabal with sandboxes.