Stack-only install

A major benefit of stack is the integration with resolvers enforcing ghc version compatability, and the combination of the stack api with an ability to automatcally drop back to cabal.

Would it be possible to create a stack-only installation where cabal and ghc continued to be managed by stack. Maybe they are greyed out in ghcup list?

Would hls be problematic in this situation?

A major benefit of stack is the integration with resolvers enforcing ghc version compatability

You can do exactly the same with cabal.

and the combination of the stack api with an ability to automatcally drop back to cabal.

I don't understand this sentence. Stack doesn't have the ability to drop back to cabal.

Would it be possible to create a stack-only installation where cabal and ghc continued to be managed by stack.

This makes no sense. Stack cannot manage cabal.

---

Overall, I don't understand your question.

added statusneed-info typediscussion labels

For reference, I was motivated to ask the question after reading this thread:

https://github.com/haskell-infra/www.haskell.org/pull/93

And this comment in particular:

the stack team as a whole do not regard ghcup, as it stands, an adequate installer for stack

In the abscence of concrete reasoning and details, I am trying to fill in the blanks. In my opinion, GHCUp fails to satisfy a core design feature of stack; that it manages GHC and cabal automatically for you. The current installation of stack via GHCUp does not facilitate this.

From the stack docs:

https://docs.haskellstack.org/en/stable/GUIDE/

Stack's functions stack handles the management of your toolchain (including GHC — the Glasgow Haskell Compiler — and, for Windows users, MSYS2), building and registering libraries, building build tool dependencies, and more.

GHCUp also manages GHC and cabal for you as it's core mission, and thus the operational design of the two tools might be in conflict.

If GHCUp had an option to install stack as the primary way to manage GHC and cabal, to turn these parts of GHCUp off, then this would faithfully represent the recommended setup of the stack project, so that unification and consensus would be more likely.

You can do exactly the same with cabal.

There are many crossovers between cabal and stack functionality, but this may not be a good criteria for whether GHCUp should faithfully reproduce the stack ethos. Arguing that redundancy exists leans towards arguing that stack should be deprecated in favour of cabal.

Stack doesn't have the ability to drop back to cabal.

Stack had the ability to drop back to everything eg

stack exec cabal --no-ghc-package-path -- configure

if you want to run the cabal resolver but not build.

Overall, I don't understand your question.

Apologies for the lack of clarity. Trying again, I am asking whether it is possible to install stack via GHCUp that is faithful to its core function, as documented in the stack guide. I ask the question because I think the possible answers signpost a major fork-in-the-road:

If it would be easy, then I imagine the unification benefits are numerous, even (especially) if you believe stack to be an inferior approach to GHCUp. For example, with a faithful stack installation via GHCUp, moving from a stack-based to a cabal-based workflow would become much easier, and GHCUp would become the place to document and help users make the transition.

If it is impossible or a high-cost refactor, then it would be best to caveat the stack install via GHCUp as inferior to the main method (inferior as in not the same and not in line with the stack ethos, rather than in any absolute sense).

In the abscence of concrete reasoning and details, I am trying to fill in the blanks. In my opinion, GHCUp fails to satisfy a core design feature of stack; that it manages GHC and cabal automatically for you. The current installation of stack via GHCUp does not facilitate this.

You're being confused. Stack does not manage cabal

stack exec cabal -- --help
Executable named cabal not found on path

GHCup does.

$ ghcup run -i --cabal latest -- cabal --help
Command line interface to the Haskell Cabal infrastructure
...

I'm also not really sure that you understand what stack exec cabal --no-ghc-package-path -- configure does... it creates a cabal.project.local file that stack doesn't have any knowledge about how to interpret.

The current installation of stack via GHCUp does not facilitate this.

This is also wrong.

The only issue that exists with stack + ghcup is that it's a little less ergonomic to make stack use GHCup installed GHC versions instead of installing its own.

There are two solutions:

1. use --system-ghc, which many stack users already do with ghcup and vscode-haskell. The downside is that you need to pre-install the correct GHC version for the resolver.
2. use GHC installation hooks, this has been merged and will hopefully be in the next stack release: https://github.com/commercialhaskell/stack/pull/5585

There are many crossovers between cabal and stack functionality, but this may not be a good criteria for whether GHCUp should faithfully reproduce the stack ethos. Arguing that redundancy exists leans towards arguing that stack should be deprecated in favour of cabal.

ghcup doesn't care whether stack or cabal are deprecated. And ghcup will not get into the discussion of this.

I myself have an opinion about it, but not as a ghcup developer.

So this discussion is irrelevant to this project.

Apologies for the lack of clarity. Trying again, I am asking whether it is possible to install stack via GHCUp that is faithful to its core function, as documented in the stack guide.

Yes. You run ghcup install stack and use stack normally. That is faithful to its core function.

Closing this ticket since there's really no action item here.

If you're curious about better integration of stack and ghcup in the sense that stack re-uses GHCups GHC installations, see #392 (closed)

closed

removed statusneed-info label