Stack workspaces?

[damienstanton]

Hello all, I have a couple of questions on the module system using stack:

1. Is there any resource that the community recommends for locally-dependent packages using stack?

My goal is to learn how to develop packages which can rely on each other in either a flat or hierarchical way without needing to publish that code as a bundle to a repo like hackage, similar to how one can work locally with cargo workspaces in Rust or yarn workspaces in TypeScript.

2. If I have the stack/ghcup integration setup, does this mean that packages compiled locally for that particular resolver will be “available” in some env thag matches the ghc in ghcup, similar to how they would be in a cargo env that matches some rustc compiler?

Thanks in advance!
D

[Lsmor]

@damienstanton

Is there any resource that the community recommends for locally-dependent packages using stack?

The very same stack documentation has info about this. Essentialy, you specify in your package.yaml the local libraries your project depends on as an extra-deps witgh the path to your local library.

Notice that local libraries are treated differently if they are part of your project (in which case, they are specify under packages tag) or dependencies for your project. In the linked documentation you have all the info.

@damienstanton

If I have the stack/ghcup integration setup, does this mean that packages compiled locally for that particular resolver will be “available” in some env thag matches the ghc in ghcup, similar to how they would be in a cargo env that matches some rustc compiler?

I am not really understading what you mean here. If you build something with stack it will be bounded to a particular ghc version (the one used by the resolver) but not to any ghcup version since ghcup mission has nothing to do with compilation or packaging.

AFAIK, stack uses internally isolated environments for every resolver. I Don’t know the details, but I think it answer positively to your question

Does it answer your question?

[damienstanton]

Thanks! I had not understood the packages key properly.

As for ghcup + stack, this is a recent change which upon ghcup setup of stack directs stack not to use its own isolated resolver envs, but instead to use whatever you have installed and set as default via ghcup: Finalize stack integration (#392) · Issues · Haskell / ghcup-hs · GitLab

It’s super convenient, and actually reading more about the resolver answers my second question too. It’s more or less like cargo/rustc which is where I’m coming from.