Allow `lorri watch --once` to be executed from a sub-directory

[surajbarkale]

Feature description I have often tried to execute lorri watch --once from a sub-directory and realized that I need to run it from project root directory.

Possible implementation We can add env = "IN_LORRI_SHELL" for the command line option --shell-file and change locate_file::in_cwd to handle the absolute path to shell.nix file.

I am happy to work on a PR if you are OK with this direction.

[Profpatsch]

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 in a lorri shell, no?

[surajbarkale]

I have created https://github.com/target/lorri/pull/410 to illustrate the approach. I have found that IN_LORRI_SHELL is also set after $(lorri direnv) is evaluated in .envrc

[curiousleo]

Hi @surajbarkale! I think that understanding your use case better helps us evaluate this issue and your PR. What is that you are trying to achieve by running lorri watch --once inside a lorri shell?

[surajbarkale]

Here is my workflow:

1. Run lorri init within a monorepo ~\Documents\monoproj
2. Open VS Code to edit stuff within ~\Documents\monoproj
3. Change to a project in a subdirectory ~\Documents\monoproj\nodejs\proj
4. At some point I realize that extra setup is needed. So edit ~\Documents\monoproj\shell.nix
5. Run lorri watch --once in terminal. To get error "ERRO shell.nix does not exist"
6. Run cd ~\Documents\monoproj; lorri watch --once; cd - to wait for evaluation.

Since I am working on different projects, I run through this at least twice a week. Note that I am not using lorri shell.

[Profpatsch]

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 daemon to be good enough to be usable in 95% percent of use-cases.

On Thu, May 28, 2020 at 2:07 AM Suraj Barkale [email protected] wrote:

Here is my workflow:

1. Run lorri init within a monorepo ~\Documents\monoproj
2. Open VS Code to edit stuff within ~\Documents\monoproj
3. Change to a project in a subdirectory ~\Documents\monoproj\nodejs\proj
4. At some point I realize that extra setup is needed. So edit ~\Documents\monoproj\shell.nix
5. Run lorri watch --once in terminal. To get error "ERRO shell.nix does not exist"
6. Run cd ~\Documents\monoproj; lorri watch --once; cd - to wait for evaluation.

Since I am working on different projects, I run through this at least twice a week. Note that I am not using lorri shell.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/target/lorri/issues/409#issuecomment-635009566, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYB5ZVLJR6Q75XIMAQJCETRTWTKJANCNFSM4NJ77HQA .

[surajbarkale]

I am using the daemon on macOS with launchctl. However, I just realized that it is unable to access files in ~/Documents folder. So I had to resort to lorri watch --once. I shall update here after diagnosing the daemon issues.

[Profpatsch]

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 [email protected] wrote:

I am using the daemon on macOS with launchctl. However, I just realized that it is unable to access files in ~/Documents folder. So I had to resort to lorri watch --once. I shall update here after diagnosing the daemon issues.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/target/lorri/issues/409#issuecomment-635269848, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYB5ZX2LPDSHVKVDZVD42DRTY7VJANCNFSM4NJ77HQA .

[surajbarkale]

I was able to get the permissions under control by granting /bin/zsh Full Disk Access in macOS. I got into the habit of using lorri watch --once as there is no feedback from the daemon about availability of shell. If everything in shell.nix is already in store then daemon takes only a couple of seconds on my machine. However, if some derivation is getting built then there is no indication to user when the environment is ready. I have to hit enter and hope for a new evaluation from direnv. Since I routinely work on multiple projects, I may be hitting this issue often.

To summarize, I have had following issues with daemon:

1. Lack of feedback from daemon when shell.nix evaluation is in progress. This is also an issue without the daemon since there is no indication that shell.nix needs to be re-evaluated. For me lorri watch --once guaranties that I am using the right environment.
2. The macOS peculiarities that make daemon management painful. This is no fault of lorri.

[Profpatsch]

I got into the habit of using lorri watch --once as there is no feedback from the daemon about availability of shell.

What kind of feedback would you prefer to get from the daemon if you could dream about your perfect setup with lorri?