On Mon, Jul 13, 2015 at 12:34 AM, Kosyrev Serge <_deepfire@feelingofgreen.ru

wrote:

...

The main reason I am using stack is for its support for building a

...

containing multiple packages. There aren't any other tools that make

Greg Weber writes: project this a

...

first-class concept that is easy to use and not buggy. In addition, stack has a first-class concept of curated package sets. All of these are required to have smooth installs in real world projects, and they aren't likely to appear in cabal-install in a short time frame.

The problem that I'm personally facing all too often, is exploratory development, where the modus operandi is to try using versions/branches that are not yet released on Hackage.

Things like this happen especially during GHC version transitions, where ghc-new buildability of libraries/tools is often in flux, and so you /have/ to chase the tail (or is it HEAD?).

As an example, the version of ghc-mod that works with 7.10 is still unreleased on Cabal -- months passed, the prospects still indefinite.

But it also happens out of plain curiosity and willingness to try out how new things could affect the way of problem expression.

For an example of that, let's take the 'nokinds' branch of GHC, where Richard Eisenberg does research on formulating GHC with dependent types.

Another situation where these things matter especially is collaborative development -- trying to help with bugs, for example.

All these things ring of the same, actually..

..where Hackage puts a mild barrier to sharing small contributions with the world, Stack puts a wall.

I think you are using the wrong terminology. You probably mean to compare "stackage" with "Hackage". But your replly is supposed to be about "stack", which has first-class support for building packages that are not on Hackage as part of your project, including fetching the package from github for you. https://github.com/commercialhaskell/stack/wiki/stack.yaml#project-config

Which is a good thing.

But also a bad one.

..and unless I'm wrong, and we're indeed moving to a world where people would increasingly use Stack, this dichotomy is /bound/ to become more pressing.

Curiously, there's a technology to solve to both sides of the story -- Nix, which was mentioned before, but I think its salient point applies especially well to this dichotomy:

1. use the existing curated releases, but also can 2. override packages with a Github fork URL, commit id and the physical checkout hash -- and have everything pick it up in a transparent, fixpoint way.

Again, there is already support for this in stack. Give it a try.

Admittedly it's not been made as trivial to use -- there's more moving parts to factor, and up until now there just wasn't any party seriously interested in doing the user-facing parts.

..And so, I can't help but wonder.. what if the Stack authors would have applied their expertise to provide the same user experience they achieved..

..but with Nix as an underlying technology?

Then stack would be forcing Windows users to use cygwin

-- respectfully, Косырев Серёга