Am I limited to working on a single package?

[philderbeast]

I have a mono-repo that has many unpublished packages, some of which depend on others.

If I use --package-yaml or --package-nix without touching --snack-nix then am I limited to working on a single package? How in snack would I have a project that includes many packages similar to the way with cabal there is a root cabal.project that can reference multiple packages.

[philderbeast]

Perhaps I can do this without a project now that haskell/cabal#5526 landed two days ago, fixing haskell/cabal#4206?

[nmattia]

@philderbeast that's a good question, and one that doesn't have an answer yet. Can you give an example project structure, and the commands you'd imagine typing? For instance it's unclear what snack ghci would do with several packages, let alone snack run.

[philderbeast]

See the tests I've added to branch repro/multi-pkg-92 where I've got one app and two libs, one dependent on the other, in the same package. The command line when squeezing multiple libs into the one package would be unchanged;

snack ghci --package-yaml=package.yaml

If multiple instances of the --package-yaml option or --package-nix option were allowed then we'd have an implicit project and the command line might look like;

snack ghci --package-yaml=lib1.yaml --package-yaml=lib2.yaml --package-yaml=app.yaml

With an explicit project like with cabal's cabal.project and stack's stack.yaml, commands for tools allow naming the focus package for the command;

> cabal new-build all
> cabal new-build lib1

> stack build
> stack ghci lib1

> snack ghci lib1 --project-yaml=...
> snack run app --project-nix=...

[nmattia]

Question: does hpack allow multiple librarys ?

master...BlockScope:repro/multi-pkg-92#diff-b70f96cd6dacdfa375dc26b966109277R3

I'll play a bit with https://github.com/BlockScope/snack/tree/repro/multi-pkg-92 and see what I come up with. I like the idea of being able to specify --project-yaml and --project-nix multiple times. Maybe the snack.nix should have a field that lists all the packages.

[langston-barrett]

More broadly, it'd be nice to be able to specify Snack packages as inputs to other Snack packages in such a way that if I change a the module in Foo.Bar in package A, only the modules in package B that depend on Foo.Bar have to be recompiled if I want to run/compile B.

My biggest pain point with Nix+Haskell is working on an executable with a deep library stack: if I change something way upstream, then every intermediate package gets recompiled from scratch, even the unaffected modules.

[nmattia]

I change a the module in Foo.Bar in package A, only the modules in package B that depend on Foo.Bar have to be recompiled if I want to run/compile B.

@siddharthist this is actually what happens in Snack! See this reddit conversation. I planned on writing up on Snack's design, I'll bump it in my todo list.