-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can we have the old API back? #54
Comments
Hmm, yeah. The fact that changing the directory with That said, for the env I get it (needed to happen, for better or worse), and while I preferred not needing to pass the And like, I do get that the path change is probably better semantics for multithreaded use. But... in the cases where I've used this library, that kind of concurrency bug isn't that likely1 than messing the path up here, so it seems like an unfortunate call (But I get that having only some of the state be global would be pretty weird, and would probably mean you need to do some locking...) I'll have to think about it. I really liked 0.1.x -- it's so nice to use and gets a lot right. So maybe I'll come around to this, it just feels like this is exactly the kind of bug I tend to end up making. Footnotes
|
So, thinking about it more, this change certainly makes the use of So yeah, it's hard for me to really act like the old semantics would be really ideal for these programs, and these semantics are consistent -- changes to the state are entirely local to the Sadly, I think how it used to work is still... kinda better for the cases1 where I reach for That is, what would a I guess something like that would end up being... an opinionated2 library for rust scripts and other
Footnotes |
So, I've been using I can't speak for others, but its kind of... genuinely error prone for me, and I have to be extremely careful about any use of
It's particularly easy to make this sort of mistake when converting code that doesn't use xshell to code that does. That said it's not limited to this, as it's also easy to miss in review too (not to mention cases like While it has gotten rarer that I make this kind of mistake, honestly it still occasionally causes issues even several months on (admittedly it's not like I am working on xtask code every day -- perhaps this is part of the issue though, if it was more regular it may be easier to avoid). I think probably the best approach for me might be to just live with not changing the CWD after creating a This kinda feels like I'm fighting the lib though, so I felt I should come back to this and say something. FWIW, unlike the process environment (which should basically never be written to), I'm not 100% sure why the current directory was moved into the While this may be error-prone if you have several threads in an xtask, it would only cause issues if you want each one to have their own current working directory, and could be avoided by not changing the working directory in that situation (not ideal, but it sounds somewhat uncommon... perhaps I'm mistaken, though). Which is the same situation I'm in, even in the single-threaded use case... That said, maybe there's some other approach you prefer (or maybe I'm underestimating how important the "many threads which change their working directories" use case is). |
Not sure how important/common this is, but I certainly had cases where I needed multiple |
FWIW I'm also quite happy that I can change_dir a shell without mutating any kind of global state. |
I recently saw the announcement of xshell 0.2. I'm a very happy user of 0.1 and can not see what having to keep around a
Shell
instance buys me. I wasn't actually aware that the process-global environment was being changed previously (though I never touched the probably more problematicpushenv
, onlypushd
andcmd!
), I would have assumed thatxshell
has its own global / thread-local / whatever state tracking that its commands use.Would you consider returning
cmd!
without the leadingsh
argument and globalpushd
(plus maybepushenv
) as a layer on top of the newShell
API?The text was updated successfully, but these errors were encountered: