Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Am I limited to working on a single package? #92

Open
philderbeast opened this issue Nov 6, 2018 · 6 comments
Open

Am I limited to working on a single package? #92

philderbeast opened this issue Nov 6, 2018 · 6 comments

Comments

@philderbeast
Copy link
Contributor

philderbeast commented Nov 6, 2018

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
Copy link
Contributor Author

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

@nmattia
Copy link
Owner

nmattia commented Nov 7, 2018

@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
Copy link
Contributor Author

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
Copy link
Owner

nmattia commented Nov 15, 2018

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
Copy link

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
Copy link
Owner

nmattia commented Feb 13, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants