Feature/1269 formalize paths in package commands #1273
Conversation
-added shell normalize_path method (does nothing as yet)
|
I didn't put a lot of thought into it, but I am tempted to say we could apply such normalization only when required. So in this case, only for the yet to be created GitBash shell plugin. I feel like it would be a much safer approach than applying normalization on all shell types. I would also make this an opt-in feature (so no default configuration). |
Well, this is what effectively happens anyway. The default impl leaves paths unchanged. The alternative would simply be checking a bool flag to see if normalisation should be done (the code responsible for applying normalization isn't isolated to each shell). So it'd end up as basically the same thing.
I'm not so sure about that, currently windows paths are getting set to (eg) Note also - this turned out to be a lot more complex than I expected, and there are more changes I need to add to this PR, so I'll probably decline and reopen it. Path normalization is more of a new feature than you'd think - currently there's the implicit assumption that paths are just system native, and not affected by the shell. You'll see all the interesting bits in the new PR, stay tuned. |
|
Ok, changes applied, including addition of new wiki entry on filepaths. To clarify my previous comment: Currently, things are working in Windows only coincidentally (in the sense that it happens to tolerate fwd slashes in filepaths). The unspoken rule so far is that paths in package commands are expected to be posix-style. This goes hand-in-hand with the expectation that env-var references are also unix-like (see https://github.com/nerdvegas/rez/wiki/Package-Commands#environment-variable-expansion). However, the fact that posix paths are expected, and that all the existing shells actually work, is basically sheer luck. The addition of the new gitbash shell (PR coming) doesn't represent an edge case - it's just the the first shell that happens not to work, because of something we didn't take into account (the need for path normalization, in order to have one common path syntax, which allows us to write non-os-specific pkg commands). Basically path normalization is required in order to have pkg commands that aren't inadvertently os/platform- dependent. Fortunately, I'm pretty sure this change is backwards compatible with existing commands that do use platform-specific syntax. Specifically, use of I would definitely highlight this info in the release notes though. |
|
SonarCloud Quality Gate failed.
|
|
I missed your last two comments. I am still against this though. I strongly believe that path normalization should not be applied to all shell types. I also think it's not too late to make this an opt-in instead of an opt-out and only enforce that when absolutely necessary (so far only for gitbash). |
|
What's your specific use case for requiring disabling of path normalisation?
My take on this is still that it fixes previously incorrect behaviour, and
does so in a backwards compatible way. I agree with the ability to disable
it for debugging purposes though, although why spend the time until there's
proven need?
…On Wed, 20 Apr 2022, 02:49 Jean-Christophe Morin, ***@***.***> wrote:
I missed your last two comments. I am still against this though. I
strongly believe that path normalization should not be applied to all shell
types.
I also think it's not too late to make this an opt-in instead of an
opt-out and only enforce that when absolutely necessary (so far only for
gitbash).
—
Reply to this email directly, view it on GitHub
<#1273 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOUSRGCMIIOZUZIWYIX2LVF3P3FANCNFSM5SSLE7EQ>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
Fixes #1269