Vision for MinGHC about minghc HOT 13 CLOSED

I agree. My only thought is that stack is less geared for tinkering and more geared for building projects. MinGHC has the advantage that you have raw access to GHC and GHCi on your PATH without needing to know much (if anything) about the ecosystem. stack sort of forces you to deal with the ecosystem (in a good way, to be sure), but it might be a big bite to chew for newcomers.

from minghc.

Now that I think about it, however, the Haskell Platform also targets that audience well, so perhaps MinGHC has been deprecated. stack is even more minimal than MinGHC is!

from minghc.

With a really easy installation procedure for stack on Windows, I think stack could be a slam dunk. (Right now you have to unzip an archive, rename a file to stack.exe, and move it to you PATH. I think we can do a tad better than that.)

from minghc.

There is value to providing an environment where Cabal works, just because all tutorials and beginner documentation references cabal and not stack. The fact that MinGHC ships alex and happy is clearly a workaround for the fact Cabal is not that good, so certainly if we defaulted to stack it would be a bit more minimal.

@snoyberg, can stack download a complete MinGHC environment? e.g. MSYS, Git, and even Cabal? Assuming it can, the two things MinGHC brings to the table are:

• You can download it on one machine and install it on another. That's valuable, although a lot less than it was 5 years ago.
• You can install it with a double click. There are plenty of Windows users who will mess up unzipping.
• You can add it to the PATH, which again, is pretty difficult for some users (and not really trivial for any, thanks to the awful UI).

My guess is that MinGHC should stay roughly as it is, but also bundle stack (does it not do that already?). Hopefully at some point in the future it will become clearer if stack wins and it can then be pared back.

from minghc.

Yes, stack downloads essentially the exact same thing that MinGHC installs. I based the stack setup command for Windows on what we found worked for MinGHC.

from minghc.

I generally agree with @ndmitchell's sentiments. With no intended offense to the Haskell Platform folk, I think MinGHC is a better place for beginners to start since it lets users more easily avoid "cabal hell" and comes bundled with some very nice tools (hopefully stack included).

Still, I expect that stack will soon have its own installer (or a PowerShell script that installs it) and there won't be a clear winner in that regard.

from minghc.

So it sounds like the consensus is probably to keep MinGHC as is, and to create a separate Stack-only installer, which is basically the MinGHC installer including just the Stack tool? And expect that in the fullness of time one of those will probably die.

from minghc.

I hadn't thought of that idea. One potential [ly bad] idea is:

• Install stack on the PATH
• Run stack setup for some version of GHC (maybe have a checkbox in the installer?)
• Add stack's managed GHC and company to the PATH

from minghc.

Around the same time this conversation got started, I visited Mark about how stack and the Haskell Platform relate. I think that that's a conversation that's quite relevant to the future of MinGHC. In theory: as the HP becomes more minimal, it may be able to replace MinGHC as the "minimal GHC installer for Windows."

Relevant mailing list post: http://projects.haskell.org/pipermail/haskell-platform/2015-July/003129.html

from minghc.

That sounds exactly like MinGHC is trying to provide - are there any differences? If so, can we just rebrand MinGHC, tweak as required, and go from there? Perhaps with @3noch as a blessed Platform contributor (my input recently has been increasingly minimal, so I see this as a @snoyberg + @3noch project where I have opinions but no real right to an "official say" anymore).

from minghc.

shrug I guess it depends on how the discussion on the mailing list goes. I see no problem with that.

from minghc.

I'm usually of the opinion that "the more the merrier" but however it pans out I am committed enough to making this work that I'll be making contributions on a small scale. I am trying hard to bring Haskell into my company and contributing to the "on-boarding" experience falls in line with that goal. I am limited, however, to about 4-6 hours a week on things like this so you can imagine I won't be contributing anything of significant size. I have zero opinions about what we call this or who does the work. All I care about is a good product and a good experience.

from minghc.

Resolved by #87, closing.

from minghc.