On Fri, Jul 24, 2015 at 11:16 AM Heinrich Apfelmus
apfel...@quantentunnel.de wrote:
Michael Snoyman wrote:
Hopefully, they come with suitable documentation. For instance, one
thing I don't understand about stack yet is in which location it
magically installs GHC and packages, and how
On Thu, Jul 23, 2015 at 1:15 AM Heinrich Apfelmus apfel...@quantentunnel.de
wrote:
Mark Lentczner wrote:
*tl;dr: We'd like to incorporate stack into Haskell Platform, and stop
shipping pre-built packages, so we banish cabal hell, and have a single
common way to 'get Haskell' that just
I'm glad to read the variety of response, and want to summarize and
respond to the most common points:
*stack is too new * *having two package managers will confuse*
— It is indeed new, though it has arrived very well formed, and has gained
a lot of users in short order. There are two reasons
On Mon, Jul 13, 2015 at 3:34 AM, Kosyrev Serge _deepf...@feelingofgreen.ru
wrote:
..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?
Backpack (very
On Mon, Jul 13, 2015 at 12:34 AM, Kosyrev Serge _deepf...@feelingofgreen.ru
wrote:
Greg Weber g...@gregweber.info writes:
The main reason I am using stack is for its support for building a
project
containing multiple packages. There aren't any other tools that make
this a
first-class
Greg Weber g...@gregweber.info writes:
The main reason I am using stack is for its support for building a project
containing multiple packages. There aren't any other tools that make this a
first-class concept that is easy to use and not buggy.
In addition, stack has a first-class concept of
The main reason I am using stack is for its support for building a project
containing multiple packages. There aren't any other tools that make 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
No - we are not talking about the upcoming, 7.10.2 HP release. It would for
the next major release after that.
Yes, stack has only been out ~1 month, but it has already shown traction in
the community, and it has a clear working solution for managing curated
pacakge sets, like Haskell Platform.
I think it depends somewhat on operating system, since there are
permissions issues to be dealt with regarding user vs global installation.
In principle though: I think the HP installers would install to a
non-stack-specific location, and then stack would simply use that GHC based
on its inclusion
*tl;dr: We'd like to incorporate stack into Haskell Platform, and stop
shipping pre-built packages, so we banish cabal hell, and have a single
common way to 'get Haskell' that just works.*
At ICFP '14, there were several long group discussions of the state of
getting Haskell, including Haskell
I’m ccing cabal-devel, as that list seems pertinent to this discussion too. In
general I’m in favor of unifying efforts such as this.
For windows, I’d still like the _option_ to get prebuilt library binaries for
the full platform db. The modularity means that they can be just downloaded in
a
I'm +1 on nailing down an LTS release cycle, I've been pushing for it, and
planning that it would happen after the first few releases. I'm fine with
doing it starting with the next release if that's desired.
The cygwin/msys conflict is a problematic one. stack has more flexibility
addressing this
12 matches
Mail list logo
