Separate out Stack.Setup to its own package

[snoyberg]

First, the general arguments back and forth: this is generally useful functionality, which can be easier to maintain as a separate package with a stable API Stack depends on. Downside: it takes work to separate it out, and maintaining changes between two packages is harder than one.

Now, specifically for this module: I have a use case (a dev environment for my kids, https://twitter.com/snoyberg/status/1032948626815901697) where I'd like to be able to write a tool that has no system dependencies and relies on a GHC installation. Currently, I have it depending on Stack being available, but it would be nice to not depend on Stack's availability.

Further, once this is separated out, I think there are some major improvements that can be made to how Stack installs and manages GHC installations, such as:

• Have a config file pointing to various GHC installations, making it easy to provide your own
• Provide an option to install GHC in a system-wide location

Maintaining this outside the confines of Stack should make it much easier to make such major improvements.

If there are no objections, I'll implement this myself in the coming week, with the kids IDE as a test case to demonstrate that it's working for both Stack and another application. I'll separate out the code into a package inside subs (still thinking of a name, ideas welcome).

[sol]

I used Stack.Setup for a standalone program in the past: ghc-env

It's bit rotten now. But I'd love to have Stack.Setup in a separate module. I hope that will make it easier to keep ghc-env working.

[snoyberg]

FYI, I'm not going to have time in the near future to do this myself. If you (or anyone else!) is interested in taking a crack in it, please say so, I'll be happy to lend some advice.

[harpocrates]

I'd be interested in taking this on, mostly because I'd really like to reuse the robust cross-platform installation logic. Eventually, I'd like to use this to create a minimal equivalent to rustup which would help me install/manage/uninstall GHC's (esp. for bindists produced in GHC HEAD's CI). This might also be useful for CI (esp. on GHC HEAD or on Windows) - I've definitely wish for such a thing for Haddock.

What sort of process do you have in mind for factoring this out? I have a week of paid time I could burn on this in December...

[snoyberg]

That's great! The way we've done these kinds of refactorings in the past is to start by moving the current code into a new package in the subs directory, getting it to compile, fixing up the code in Stack itself, and then cleaning up the API. Once things have stabilized, we then move it into its own repo. Sound reasonable?

[harpocrates]

Yes, sounds quite reasonable - I'll start poking around when I get a moment. Thanks for the prompt reply!

[qrilka]

Also it should be noted that such an effort could cross a bit with the changes I do in the new-build-plan branch (PR is to appear soon), it could be worth to take that into account @harpocrates

[qrilka]

@snoyberg so in the end we should have something like https://www.haskell.org/ghcup/ but as a library, right?

[snoyberg]

Sounds about right

…

On Mon, Mar 25, 2019, 3:04 PM Kirill Zaborsky ***@***.***> wrote: @snoyberg <https://github.com/snoyberg> so in the end we should have something like https://www.haskell.org/ghcup/ but as a library, right? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4261 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADBB2AK6BE6faQAih1SOE7rm8gacydzks5vaMlzgaJpZM4WMfz7> .