Release v1.9.0 breaks automation use-cases

[safl]

Hi,

I indirectly use your excellent module, indirectly as I use pipx. Now, my issue is that when you changed how PATH 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. Paramiko exec_command("my-command"). Basically, all forms of "automation" entry-points which uses a tool installed with pipx and having used pipx ensurepath to make sure it was available. Since, userpath no longer populate these, then this all break.

Thus, two questions:

• Why only login-shells to begin with?
• Can this be change be reverted?

Cheers,
Simon

[chrysle]

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.

[safl]

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 to pipx.

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!

[chrysle]

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.

[ofek]

I don't have time but that is desirable! Please let me know when you open a PR and I will merge and release

[ofek]

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!