nomeata commented 4 years ago

Still a new lorri user here, but that doesn't stop me from sharing some ideas.

I am a bit dicomforted by lorri changing the environment “under my feet” at a random point in time. I think I would feel more in control if

there was an indicator (e.g. a message, or as part of the prompt) when my current environment is out of date
there was another indicator telling me whether the latest environment is built and available
there is a command I can run to update then (deliberately) switch to the new environment

nyarly commented 4 years ago

320 provides the requirements for most of this. I have this as part of my prompt command:

lorri internal__stream_events --kind snapshot | jq -r --arg shell_nix $shell_nix -f ~/.config/fish/functions/lorri_glyph.jq

Where lorri_glyph.jq is:

(if .completed?.nix_file.shell == $shell_nix then "✔" else null end),
(if .failure?.nix_file.shell == $shell_nix then  "✘" else null end),
(if .started?.nix_file.shell == $shell_nix then "⏳" else null end) | values

Let me suggest that you don't actually want to delay switching the the new environment, almost ever. Consider: Lorri want's to build the environment with the dependencies as declared in the code. Almost any activity you'd want to do in a project, you want the code and its dependencies to agree. So while a warning of "deps are out of sync" is useful, you in fact want them to align as soon as possible.

nyarly commented 4 years ago

Be aware, however, there's active discussion and I intend to implement updates to the event streaming interface, in the hopes of landing it in the public interface. When that happens, you'd need to update these scripts. There'll be accompanying documentation about how to do that, however.

nomeata commented 4 years ago

The status code is a good start! (It fails spectacularly if lorri isn't running :-)).

So while a warning of "deps are out of sync" is useful, you in fact want them to align as soon as possible.

Maybe … but here is a concrete example: but mabye I am using coqide, and a shell where I repeatedly run make to update .vo files to be read by coqide. I now run git pull, which updates to a new version of Coq. If lorry makes the shell update to the new coqc, then it will produce .vo files that I can’t read from coqide. So now I am forced to close coqide and restart it. That feels invasive…

(Maybe this is rather particular, and I certainly accept “that’s not the vision for lorri”)

Profpatsch commented 4 years ago

If lorry makes the shell update to the new coqc, then it will produce .vo files that I can’t read from coqide. So now I am forced to close coqide and restart it. That feels invasive…

Does that happen often in practice? Any long-running command we cannot update (by design of POSIX) unfortunately, so I don’t see what can be done about that.

What I often do is not run the lorri daemon by default (thanks to direnv, the last state of all projects always “just works”) and start it once I start changing dependencies. That’s not the intended use-case in a perfect world, but unfortunately nix is not perfect yet :)

People have been requesting things like lorri stop <project>, but we want to keep the internal state machine as simple as possible is my take, both for implementation simplicity and the simplicity of the user interface.

If you want to experiment with different “modes of operation”, we try to expose “plumbing” commands (see lorri internal --help), so people can experiment with different workflows by scripting them together. If you miss some command/information there, please let us know. Also if you find a cool workflow we should include in the default interface.

Profpatsch commented 4 years ago

* there is a command I can run to update then (deliberately) switch to the new environment

That’s effectively “build in the background but don’t symlink the gcroot yet”, right? I wonder if we can already script that with the existing plumbing commands.

nomeata commented 4 years ago

What I often do is not run the lorri daemon by default (thanks to direnv, the last state of all projects always “just works”) and start it once I start changing dependencies. That’s not the intended use-case in a perfect world, but unfortunately nix is not perfect yet :)

I guess that’s what I do as well so far, simply becaues I didn’t bother setting up the service yet (and I don't trust this new tool enough to be completely out of sight). So maybe that’s good enough for me as well :-)

symphorien commented 4 years ago

Thanks for the script in https://github.com/target/lorri/issues/365#issuecomment-606835166 . I use it in my shell prompt, now. My previous workflow was : cd, and run nix-shell. The new lorri one is : cd, and type enter until the prompt says the shell is ready. Without this indication, there is no way to know if lorri is not finished building or if the shell failed to evaluate. When asking in irc, I was told I can run nix-shell to see if it worked, but then I have no improvement on my previous workflow: cd, and the run nix-shell to know whether lorri succeeded or failed.

For this reason, I think there should be a non-internal command we can rely on to implement such a prompt. Something like lorri build-status which returns an exit code. Additionally, something like lorri wait which waits for build completion and if the build failed, prints the error, would be a bonus.

Profpatsch commented 4 years ago

The new lorri one is : cd, and type enter until the prompt says the shell is ready.

You should immediately see direnv output if you have built this project before. You can usually immediately start working, unless e.g. you switched to a different branch that has features you need.

Something like lorri build-status which returns an exit code. Additionally, something like lorri wait which waits for build completion and if the build failed, prints the error, would be a bonus.

Yes, we should add a user/script friendly command like that. I believe there is an issue open about adding one.

On Tue, Apr 28, 2020 at 10:39 PM symphorien notifications@github.com wrote:

Thanks for the script in #365 (comment) https://github.com/target/lorri/issues/365#issuecomment-606835166 . I use it in my shell prompt, now. My previous workflow was : cd, and run nix-shell. The new lorri one is : cd, and type enter until the prompt says the shell is ready. Without this indication, there is no way to know if lorri is not finished building or if the shell failed to evaluate. When asking in irc, I was told I can run nix-shell to see if it worked, but then I have no improvement on my previous workflow: cd, and the run nix-shell to know whether lorri succeeded or failed.

For this reason, I think there should be a non-internal command we can rely on to implement such a prompt. Something like lorri build-status which returns an exit code. Additionally, something like lorri wait which waits for build completion and if the build failed, prints the error, would be a bonus.

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

nomeata commented 4 years ago

I just upgraded lorri to latest master, and wanted to play around with something like described in https://github.com/target/lorri/issues/365#issuecomment-606835166 but it seems that lorri internal stream-events --kind snapshot is now empty.

I’d like to re-open this issue: A prompt indicator that tells me “this a lorri-managed directory, and the lorri environment has loaded, and whether it is up to date, or whether lorri is building, or whether the lorri daemon is away would greatly increas my confidence in that tool.

Or maybe a first quick-to-run lorry status that tells me these things…

Then I only need a quick way to see the build logs from lorri (I sometimes have problems connecting to nix caches and lorri might go off rebuilding the world) to be happy :-)

Profpatsch commented 2 years ago

I found two different instructions on how to update fish and zsh asynchronously:

https://github.com/acomagu/fish-async-prompt https://www.anishathalye.com/2015/02/07/an-asynchronous-shell-prompt/

target / lorri

Prompt indicators / reload on demand #365

320 provides the requirements for most of this. I have this as part of my prompt command: