-
Notifications
You must be signed in to change notification settings - Fork 69
Conversation
0777d29
to
3a072dc
Compare
Rebased this now, so it's just one small commit. |
Not to bring up unnecessary bikeshedding, but what about |
Sounds a little bit evil based off of the description of the "build" command in previous versions. I still think |
3a072dc
to
07b45fe
Compare
After some deliberation, we decided we’d ideally call it |
You could call it "run", but having it be under a flag for watch is probably the worst one for usability. There's no way a new user will find this readily, and there's also no other tools I use where I say "watch my files to build but do it just once". |
True, @grahamc should we just add the new command now? |
I'm going to change this back in my branch because 1) I already use this 2) I have some other people also using this 3) there should be a separate command for this action. It really makes no sense to make the UI of this tool so confusing as to introduce a bunch of its own terminology. |
07b45fe
to
0777d29
Compare
0777d29
to
7094ad6
Compare
Overall the code in this PR looks fine and I have no objections to the code itself. However this is not the direction that we want to go with lorri right now. lorri is intended to be used with the watcher going continuously and if this causes any problems then we should try to tackle the actual problems and not try to come up with workarounds. Having an option to Could you maybe elaborate a bit again on your usecase scenario that made you want this command? Is adding |
I don't change my shell.nix constantly, so I don't want to run a watcher or daemon to try to constantly listen for changes, ever. When introducing me to lorri, Profpatsch had me run What I want to have is what lorri does currently, but with the I don't see what "watch once" does other than just obfuscate using this command. I understood that lorri is supposed to be about installing dependencies for my development environment, which is why I explicitly want to "install" these once given that I am not changing them at the given moment I run this install command. |
The daemon is designed to be near-zero overhead (once we get a good grip on how many files are watched), but I can understand that people don’t want to run anything permanently that they don’t regularly use/need. Graham is the main author of this project, so he has the final word on what he wants to be the focus and what not. I assume it’s fine with you @justinwoo if such an operation exists at all, regardless of how discoverable it is. |
The overhead is not an issue with me as much as knowing when and why something will change. I am not actually fine with such a command existing "regardless of how discoverable", which is why I'm talking about this so much in here. I would really like to avoid being asked for support about something we can make readily usable now rather than later. |
Heyo, not an active user yet (but I’ve been looking at Just wanted to say that, from a conceptual perspective, It feels as if it embraces the notion of tying some incidental behavior (installing the dependencies in a given It makes sense that Does that make sense? |
We decided to add |
Adds a simple install command, so that users don't need to run
lorri daemon
orlorri watch
just to have the shell root built. This makes lorri conform to most people's expectations of how tools like this work, where you have aninit
phase that initializes config, and aninstall
phase that will do the setup based on the current configuration.This really only does the same thing as
watch
but using theonce
mode of the build loop.Based off #122, preventing merge conflicts. Can be rebased when needed.