Open idontgetoutmuch opened 6 years ago
Sorry for missing this. I use a shared stack.yaml
and shell.nix
for a handful of related packages, and didn't properly verify that the new setup just for Frames
was complete.
I've added a shell.nix
to the repo, but I did this as part of a few changes that included changing the type of a couple exported names (mapMethod
and mapMethodV
). This requires a major version bump of the package. I haven't uploaded to hackage yet, but I'm now wondering if I should cut a release with a minor bump to include the shell.nix
. I think the previous messed up state (missing the shell.nix
) doesn't affect downstream users, but if you wanted to work on Frames
, but did not want to pull in a major version change, I'd be willing to do another minor release.
If you're fine with a major bump, then we can just move forward.
regarding the shell.nix, it assumes that you've cloned Vynil which is not practical:
vinyl = pkgs.haskell.lib.dontBenchmark (super.callPackage ~/Projects/Vinyl {});
Yes, it's not used to build releases as of yet and only for the sake of development; anyone wanting to make use of it edits it to suit their setup.
If there is a desire for a more portable version, I'd like to figure out how to make things automatically work with direnv
. We've done a Vinyl
git submodule before, so that's an option again, though I felt that was clunkier than just having a side-by-side checkout with nix
pointing to that. So what is needed is a setup where we can have a shell.nix
for people sure they won't need to touch Vinyl
, and one for folks who think they might, such that direnv
does what is wanted. I imagine this is possible, but didn't figure it out with a quick look at how nix-direnv is put together. I think this is the relevant line of nix-direnv
that ideally we could instrument with a parameter or something in .envrc
to control which variant of the shell.nix
control flow is taken.
~/.local/bin/stack --nix build error: getting status of 'Frames/shell.nix': No such file or directory