Open safl opened 11 months ago
Why only login-shells to begin with?
This has been done to avoid breakage, because it's not guaranteed that a .bashrc file exists or would be used if created, but it is that a login file exists, since that is the concept of login shells. The discussion was about removing one of the components, to avoid duplicate entries to both login and configuration files.
Concerning your issue, one way would be to run your command with SSH specifying to use a login shell, e.g.: ssh foo@bar bash --login -c "my-command"
. Of course this would complicate the workflow.
However I'm also working on a command-line option to specify the file to add the PATH
to, which could probably be added to pipx
.
Why only login-shells to begin with?
This has been done to avoid breakage, because it's not guaranteed that a .bashrc file exists or would be used if created, but it is that a login file exists, since that is the concept of login shells. The discussion was about removing one of the components, to avoid duplicate entries to both login and configuration files.
I see, thanks for clarifying. From my perspective, then I prefer having duplicate entries that covers more use-cases rather than a "cleaner" non-duplicate that only works for login shells. To me, then this change was a functional regression.
Concerning your issue, one way would be to run your command with SSH specifying to use a login shell, e.g.:
ssh foo@bar bash --login -c "my-command"
. Of course this would complicate the workflow.
Yes, that is one work-around, and paramiko can facilitate this with get_pty
, however, then it becomes a trade-off of having a bunch of other issues to deal with. That is, the various features enabled for login-shells, when running commands in a "exec" environment.
However I'm also working on a command-line option to specify the file to add the
PATH
to, which could probably be added topipx
.
This is closer to a solution that would be usable for the pipx ensurepath
use-case / automation, from my point of view. Are you somewhere along the lines of --login-shell-only
? It would be great if the previously behavior was "re-instated", and then the new "flag" would introduce the "new" behavior.
And by-the-way, I am just an opinionated user, thanks for providing an awesome Python module. It was not until the pipx ensurepath
behavior broke for me that I found out about userpath
. I have really appreciated the pipx ensurepath
and now realizing that this module brought the functionality is great to know. So, thanks!
This is closer to a solution that would be usable for the
pipx ensurepath
use-case / automation, from my point of view. Are you somewhere along the lines of--login-shell-only
? It would be great if the previously behavior was "re-instated", and then the new "flag" would introduce the "new" behavior.
This sounds reasonable to me. I might do that, thanks for suggesting.
I don't have time but that is desirable! Please let me know when you open a PR and I will merge and release
I temporarily reverted the breaking change until the optional functionality is implemented https://github.com/ofek/userpath/releases/tag/v1.9.1
@chrysle please let me know how I can help with that!
Hi,
I indirectly use your excellent module, indirectly as I use
pipx
. Now, my issue is that when you changed howPATH
is defined. Explicitly this is causing me grief:On non-Windows systems only modify login shells
.Thus, whenever I do e.g.:
ssh foo@bar "my-command"
, then it fails, or when using e.g. Paramikoexec_command("my-command")
. Basically, all forms of "automation" entry-points which uses a tool installed withpipx
and having usedpipx ensurepath
to make sure it was available. Since,userpath
no longer populate these, then this all break.Thus, two questions:
Cheers, Simon