-
Notifications
You must be signed in to change notification settings - Fork 787
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
fix!: do not remove items from PATH in POSIX entrypoint #1521
Conversation
I can't quite remember the scenario under which we added the "removal and then add" of items to PATH, but it solved some problem... 🤷 Given this is effectively part of #1480 and a breaking change alongside it, I will merge so they can be tested together by those utilising the repo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, let's merge to let people test this alongside #1480
I suppose it's possible a user in an interactive shell sources If we want to support that behavior, then in my opinion we can just unconditionally append to the path (removing the case statement). That way it will work even if the user it in Dash or Ksh or whatever. I guess that'll make PATH slightly longer, but 🤷 . |
Having asdf prepended to PATH seems to be the preferred behaviour from our existing and historic user base. See this recent discussion #1496 (comment)
The introduction of the preprend to PATH was to resolve issues people had with over population of PATH. Many people cared about having a clean PATH, so appending data to PATH and unnecessarily increasing PATHs length is not preffered. This is a reason as to why I was suggesting we have an entrypoint script for each Shell we support, even if they have a 90% overlap in implementation, this way simplifications to the code to ensure it works across all Shells does not interfere with existing behaviours of other Shells. So yes, I think we will need to modify this to prepend as it did previously and to align with Elvish/Fish/Nushell behaviour. Whether or not we remove from PATH first really depends on how people source asdf, so that we only prepend once or if we re-run this code a lot, only prepend if it is not in PATH. Again, I am fuzzy on why we did the removal and then addition instead of just not adding if it was already in PATH. |
I was a bit confused reading your response but I think that's because we have different definitions of prepend. When I use prepend, I'm strictly talking about the act of adding strings to the beginning of PATH, conditionally (ie only if string is not somewhere in PATH) or unconditionally. But when you use the word, you mean that the string must always be at the beginning after prepending, correct? I think even with the definition I think you're using I'm still confused but I think I understand the outcome you prefer.
I see what you mean now and I apologize for that.
I checked the scripts again and I'm more confused since those three shells don't seem to have consistent behavior?:
Both methods keep a "clean" path, but only the first ensures that asdf remains at the beginning of PATH if The first one is what we want to go for, right? I should revert most of these Bash/etc. changes, and change Nushell and Elvish so their behavior matches Fish and the old Bash behavior? |
Sorry for the confusion. My incorrect recollection was that Nushell/Elvish were implemented the same as Fish.
I prefer this method as it preserves user's custom configuration if they decide to add asdf to PATH themselves. In my opinion there is no need to revert. I think we just need to update Fish to align with everything else and perhaps update the docs to communicate we prepend dirs if not present in PATH. |
👍
Sounds good! I can make a PR that does that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
String is put at beginning of PATH, but only if the string isn't already in PATH
I think you made the right choice in selecting this approach.
Previously, loading ASDF_DIR/asdf.sh rewrote ASDF's placement in PATH, which required only loading it in root shells, and loading ASDF_DIR/lib/asdf.sh in subshells. asdf reworked asdf.sh in asdf-vm/asdf/#1480 and asdf-vm/asdf#1521 and removed ASDF_DIR/lib/asdf.sh in asdf-vm/asdf#1525, which makes this workaround no longer effective. Instead, manually add ASDF_DIR/bin and ASDF_DATA_DIR/shim to PATH directly in root shells and load ASDF_DIR/asdf.sh in all shells (since it no longer messes with PATH).
Have you considered using I agree the new behavior is better, but I don't find the lack of pattern substitution in POSIX variable expansion a compelling argument to introduce breaking changes when it could just run POSIX |
@gabrielsoldani is this a breaking change? Both this PR and #1480 (comment) are labeled fixes. |
@gabrielsoldani is this a breaking change? Both this PR and #1480 (comment) are labeled fixes.
Yeah. Previous to this change, on bash and zsh, `asdf.sh` checked if the
`PATH` already contained the bin and shims directories, and if it did, it
removed them and prepended them, ensuring asdf is first in the `PATH` after
sourcing the file.
Now, to get the same behavior in zsh and bash, you need to set
`ASDF_FORCE_PREPEND` to `yes` (it defaults to `no`, except on macOS where
it defaults to `yes`, so this is not a breaking change for macOS) (see
#1560).
To avoid the breaking change it could simply default to `yes` everywhere.
|
@gabrielsoldani The changes were made to make the behavior consistent across shells (the ones asdf supports) and user expectations and other tooling. If every tool automatically forcefully made themselves the first entry in the PATH, the user would have no control when they should. I only mention the non-POSIX pattern substitution because that adds to the inconsistent behavior (sourcing same file, different results). Nothing was changed solely because pattern substitution in variable expansions is not in POSIX - as you can see in the final Your points about this being a breaking change (this PR, #1521, unrelated to #1480) are correct and were discussed, which is why I authored #1560 so users could explicitly choose with the variable. But yes, it does not default to |
This is a good point. It is breaking because we changed the default. But I think this is a necessary change. I'm going to catch up on what was discussed in #1579 next. |
@Stratus3D The
We also have the setting for the
Set to Hope that clarifies the linked |
Summary
The PATH issue was briefly mentioned in the original POSIX entrypoint PR, but it was not fixed there.
The issue is that previously
asdf
modified the PATH variable, and removed the asdf bin or asdf shims directory (from PATH) if they existed. Besides not being good practice (in my opinion), this had issues since this behavior would only run under Bash and ZSH (POSIX doesn't support substitution in parameter expansion and I intentionally didn't add this behavior to KSH for simplicity). Since the same script could change PATH differently (when ran under different shells), this can be confusing behavior. Also, neither the Elvish, or Nushell scripts remove items from the PATH, this also could be confusing.These changes make it so the POSIX entrypoint match the Elvish,
Fish, and Nushell behavior by only adding the bin and shims directory if they aren't already in the path.Tested with Zsh, Bash, Dash, Ksh, Mksh
Edit: These changes don't match Fish behavior, I didn't read the
asdf.fish
correctly