Profpatsch
Profpatsch
`lorri direnv` *does* run the `shellHook`, however inside of the nix build, which is probably why you are seeing the build error.
This is another datapoint that we should probably not be running any `shellHooks` in lorri (cc @grahamc)
> From a user perspective this doesn't justify not running shellHooks in lorri. I have a shellHook there so that the cabal file is reliably in sync with the package.yaml...
Usually it’s useful to distinguish between external and internal dependencies. nix is pretty granular and perfect for setting up the environment. But for internal dependencies a more fine-grained build manager...
Sounds like that could work, yes. In the end, you always need some triggers that tell your build system to run, so whether it’s a watcher or something else is...
If it is inside your project, you can use https://github.com/siers/nix-gitignore (which went into nixpkgs master a month or so ago) or https://github.com/Profpatsch/nixperiments/blob/master/filterSourceGitignore.nix (which is a bit more restrictive but should...
Update: we have implemented the `default.nix` logic now. If you can, please try out the https://github.com/target/lorri/pull/146 branch (you can clone, switch to branch and then use `lorri self-upgrade local /path/to/checkout`...
lorri doesn’t have a notion of a project, checking for a `shell.nix` in the current directory was more of a convenience. `IN_LORRI_SHELL` would only be set if you are already...
This sounds like a perfect use-case for `lorri daemon`, any reason why you don’t want to use that? `lorri watch --once` is more of a debugging tool, we want the...
What happens if you run the daemon in a terminal? I assume `launchctl` sandboxes it too strongly by default. On Thu, May 28, 2020 at 12:58 PM Suraj Barkale wrote:...