Feature Request: Please don't modify my dotfiles

[markfaine]

• [x ] I have searched the issues of this repo and believe that this is not a duplicate.
• [x ] I have searched the documentation and believe that my question is not covered.

Feature Request

Please don't modify my dotfiles when installing. This is just bad form. The default should be to expect the user to do this. Providing an option to do it in the installer is fine, it should just not be the default.

[jacebrowning]

Isn't that the sole purpose of the installer -- to get poetry added to PATH?

[markfaine]

No, just to install it. Which would include downloading it and any dependencies, basically, ensuring it will work if called directly. Though, of course it can optionally add it to the path.

[pmav99]

@jacebrowning Poetry needs to be installed in a different python distribution (think virtualenv) than your main project, because poetry itself and your own project might have conflicting dependencies.

[markfaine]

Ok, I get that but I don't see what that has to do with modifying my environment files. It's just adding the path to poetry to the PATH environment variable. I'd rather always manage the path myself and not have every tool I install modifying PATH. It's a very slippery slope and before you know it you have a terribly cluttered path, you have no idea what is in your dotfiles, and you've lost all control over the environment. Like most users of *nix based operating systems, I have custom dotfiles that take care of managing PATH (along with everything else) and I want to maintain absolute control over it. This is not an uncommon opinion, in fact, I'd say it's probably the prevailing opinion.

[neighthan]

I just found poetry today and was going to post this issue if it wasn't already here. I think asking to add it to my path is great; some users might not mess with dotfiles much, and that could be a good convenience. I keep my dotfiles in a git repo, though, and share them across machines, and I don't like them having random things appended.

[markfaine]

What I see most tools do is output a message at the end, something like: Please add the following to your .bashrc... Prompting to add it is okay too I guess, so long as there is still a non-interactive means of installing.

[neighthan]

Is this fixed already? I just installed poetry again (on Windows this time), and this is the first thing that comes up:

>python get-poetry.py
Retrieving Poetry metadata

Before we start, please answer the following questions.
You may simply press the Enter key to leave unchanged.
Modify PATH variable? ([y]/n)

[Calinou]

I just tested on a VPS where I added $HOME/.poetry/bin in my PATH before running the install script (and after logging out and back in to apply the change), but export PATH="$HOME/.poetry/bin:$PATH" was still appended at the end of ~/.profile (where my PATH is defined).

I would expect the script to check whether the directory is already in the PATH before appending it :slightly_smiling_face:

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Calinou]

As far as I know, this issue is still relevant :slightly_smiling_face:

[13k]

As far as I know, this issue is still relevant 🙂

I know it's outdated practice, but... 👍

[MestreLion]

No other tool I'm aware of permanently change's the system or the user's $PATH at install time by modifying files such as .bashrc. No tool or software should ever do that. Not even as an option, let alone being the default choice. Every *nix software created in the last decades simply copies or symlink it's executable to a predefined path where it's assumed it'll be on $PATH, be it /usr/bin, /usr/local/bin or ~/.local/bin. It's not packages installer's job to change $PATH. It's the systems' or local admin or user's resposability to provide a place for installers to put binaries to.

It's sad that XDG_BIN_HOME didn't make it into the spec, but virtually all linux distros already add ~/.local/bin to $PATH in their default ~/.bashrc. Pip already uses it without fiddling with $PATH, so in this regard it does the right thing. Poetry is supposed to be an improvement over pip! So just use that path and leave the dotfiles alone!

[MestreLion]

Besides, it's technically impossible to properly make sure you are editing the right dotfile. What if I rely solely on ~/.profile or /etc/profile and don't even have ~/.bashrc? What about ~/.bash_profile? What if I moved them somewhere else? What if I don't use bash at all, but another shell like zsh?

And I'm not even talking about PAM and its /etc/pam.d/login, or OpenBSD's /etc/login.conf, or /etc/environment. Just look at http://mywiki.wooledge.org/DotFiles to see how complex this is. It's insanity to keep track of so many scenarios and variables and corner cases. Is Poetry really going down this rabbit hole, or just make a half-backed, "works for me and cover the basic scenario" solution?

But the good news is: you don't have to. This is not your burden. So don't. :-)

[13k]

No other tool I'm aware of permanently change's the system or the user's $PATH at install time by modifying files such as .bashrc.

To be completely honest, there's a lot of them that do: yarn (forced), nvm (forced), rustup (option to opt-out). It's a questionable trend that started, IIRC, with these tools that change the environment.

Many others adopt the sensible choice and only instructs the user to edit their env files manually: kiex, rbenv, pyenv.

I get that maintainers would like to make it easy for users, and a lot of the users don't seem to understand shell environment basics (check this nvm issue, it dates back to 2014 and people are still posting comments as of 2 weeks ago), but it seems to be a double edged sword, it helps (in the very basic cases) but also causes a lot of confusion (in all other cases).

[MestreLion]

I wasn't aware of this trend, thanks for pointing it out. It's a sad and quite disturbing one. I wonder if (and how) those tools go through all the loops and hoops of the technical challenges I mentioned set a user's $PATH.

I believe instructing the user is the best choice. And since most distros already already add ~/.local/bin to the default $PATH, Poetry will already work out of the box, maybe only requiring a logout/login (Ubuntu only add if path exists, so relogin is necessary if Poetry is the first executable there). Since pip already install console scripts there chances are not even that will be necessary.

Changing $PATH properly is technically infeasible. I truly believe the only sane approach is to simply inform the user. A simple message like this would suffice:

Poetry's executable was installed as ~/.local/bin/poetry. Make sure this directory is in your $PATH. In most distros and systems only a relogin might be necessary

Or even better, since it's quite easy to test if a command is in PATH after install with a simple type poetry &>/dev/null and only show the message if the test fails:

Poetry's executable poetry was installed at ~/.local/bin, but it seems this directory is not in your $PATH. Please edit your environment before using Poetry. In most systems only a relogin is necessary.

[MestreLion]

Poetry is a dependency manager mostly used by project developers, not end users (those can simply pip install --user poetry or directly pip install the desired project without using Poetry at all). So the target audience are programmers dealing with Python coding, most likely Git version control, and, since we're discussing .bashrcand dotfiles, Linux/Mac users. They know how to change their $PATH, there's no need of that level of hand-holding.

[syntaxman]

Isn't that the sole purpose of the installer -- to get poetry added to PATH?

That response skirts the issue. The immediate issue is that dotfiles are changed without warning or request. Ensuring the command is executable is the primary purpose of the installer. Modifying PATH is only one way to do that. The vast majority of installers choose a place on the PATH to put executables. This is the actual issue. Simply use the XDG standard. The poetry package could be installed in XDG_DATA_HOME with a symlink from the executable to the $HOME/.local/bin/ location. Pipx does this, and it works great. For both Windows and XDG standard systems, the ActiveState/appdirs project (github and PyPI) allows/helps you put the data, executables, configs, and cache, in the right places. I think this is the right solution that addresses the underlying issue. I really can't remember any python package or app ever needing to edit my shell configs. (BTW, .zprofile for zsh is read for all login shells, but it isn't read for all interactive shells. My terminal apps don't start up login shells. .zshrc is the one that will run for all interactive shells.)

[bodograumann]

:point_up: Yes, please just install into ~/.local/bin!

I would have even preferred to install it through the system package management, but it is not available there :disappointed: . So I took a short look at the installer code to make sure it doesn’t mess with the system too much, and there seemed to be some interactive decision whether to modify the config files and add the poetry PATH. To my surprise, this did not get triggered.

Now the fact that you are simply messing with my personal config files and this important issue has received no attention for 1.5 years really makes me reconsider whether I should be using poetry...

---

I looked at the installer code again and the issue seems to be that the suggested installation method is not interactive and thus does not allow querying whether you want to have the profile configs changed.

curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python

So my suggestion would be to change the installation instruction to:

curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py > /tmp/get-poetry.py
# Please inspect /tmp/get-poetry.py to make sure it does not contain malicious code.
python /tmp/get-poetry.py

What do you think, @sdispater?

[Calinou]

@bodograumann There's a pull request that implements this already, it just needs to have merge conflicts resolved and can then be merged: https://github.com/python-poetry/poetry/pull/2001

[bodograumann]

Thanks for pointing me there, @Calinou. I am definitely in favour of that PR.

What I disagree with is, that it “implements ‘this’ already.”. When following the poetry introduction, you automatically run the non-interactive installation and will still have your config files modified. So I stand by my suggestion that the introduction should instruct users to do an interactive installation.

If only #2001 is merged, the introduction should at least mention the new parameter.

2002 also goes along these lines.

Neither here nor there have there been any comments / feedback from the maintainers.

[finswimmer]

Hello,

this feature was implemented with https://github.com/python-poetry/poetry/pull/2292.

But I agree we should document it on the introduction page.

fin swimmer

[jessaustin]

That PR still talks about $POETRY_HOME. That's not a thing that modern Linux users care about. Our other tools follow the XDG spec. Really old tools that don't know about that still know about ./configure --prefix, and also they default that sensibly to /usr/local. The best tools allow the user to choose either of these standard techniques, which both work well with standard tools like stow. Thankfully, few tools just make up random new directory pollution to annoy us. (yarn and nvm are called out upthread, but honestly npm doesn't follow the rules either. For node, use n if you can!)

It would be one thing if the package in question were something unrelated to installation. Installation seems to be kind of the point here, so getting it this wrong calls the whole enterprise into question.

[codeman101]

To those who are for not having the poetry installer add a line to the zshric file I'm having time understanding what you're saying should be done alternatively to solve the current issue where upon installing poetry with curl the zsh shell doesn't see where poetry is. As a major Linux/Unix user myself I don't understand the fear of having it modify the dotfile when the tool is unusable without doing so.

I'd rather always manage the path myself and not have every tool I install modifying PATH. It's a very slippery slope and before you know it you have a terribly cluttered path,

I disagree. I enjoy having to solve problems on my Linux rig but that doesn't mean I would enjoy having add every tool/app I install to my shell path manually. Even if I was a gentoo user I don't see why I would enjoy having to that manually every time. (in other words a user who enjoys customizing their install of the OS to an extreme degree) (no offense to gentoo I strive to become as intense with OS customization as gentoo allows but I'm trying to make a point here) As another example just because someone enjoys editing their dotfile to customize the color scheme of their shell doesn't mean they want to manually add every tool they install to the shell path.

If the argument is to do something like have the installer put poetry in $HOME/local/bin I'm down with that since zsh should be able to automatically see it there. Either way something should be done ASAP because on Mac at least as it stands right now poetry is unusable without doing something manually post install.

[bodograumann]

TLDR: Yes, put it in ~/.local/bin please.

@codeman101 Manging the path ourselves, doesn't mean manually adding every new application to the PATH. Most things are installed on a system level and are immediately available. The next most common thing (at least for me) is to install something locally to a project, e.g. with npm, pip, composer, … It is then available via entering the virtual environment or calling it through npx.

Then there is a small number of applications that need to be installed not on the system-level nor on a project level, but on the user-level. Even for these there usually is an easy answer like pip --user or npm --global with prefix set to ~/.local. I only had add ~/.local/bin to the PATH once. Now when, for some reason, there is no such easy answer, I can still install the application anywhere and then ln ~/my/install/location/bin/foo ~/.local/bin/foo.

So on my system there is never a reason for an application to modify any of my profile files and add itself to the PATH. Sometimes I even want to keep applications off my PATH anyway. Maybe I'm just trying it out and throw it away again afterwards.

[codeman101]

@bodograumann

So it sounds like you're arguing for poetry to only be installed via pip or some package manager thereby making it only available in virtual environments. I'm down with making that transition but I would highly recommend that if that is done the links to installing and via curl be removed because technically they wouldn't work anymore. (Well you know what I mean they would work but not fully as per this discussion.)

[markfaine]

It doesn't matter much to me how it's installed. I have functions in my dotfiles that manage this for me. I keep a separate file with paths to add to the path. I have a function that manages paths, allows me to append or prepend paths to the path and prevents duplicate paths. I don't think I'm an exception, there's about as many was to manage path as you can imagine but the key point is that I'm managing it. Again, I think this could probably be solved with a prompt.

[gragib]

pip install pipx
pipx install poetry

[syntaxman]

@jacebrowning @finswimmer @gragib @codeman101 Pipx is, by far, the solution that I would prefer to see poetry use for installation. It would move the installation directory so that $HOME isn't so cluttered, and it would put the executable in the existing path. I tried to install that way several months ago, and pipx got confused. Pipx relies on entry points, and IIRC, this was why pipx installed poetry incorrectly. Anyway, pipx would be ideal, but I'm guessing you'd also need to change how plugins are installed and detected, too. (pipx has an "inject" subcommand that would allow adding a plugin lib to an existing poetry installation) I generally change $POETRY_HOME, and manually link the poetry executable into ~/.local/bin. My main objection to having the installer modify .zshrc is that I have added a fair amount of stuff in there. I don't feel warm and fuzzy about a program making changes to it, especially when we could just put the executable in the existing path.

[gragib]

I do not use any plugins (yet). I have been using poetry installed using pipx for about a month and have not noticed any regressions.

[horseinthesky]

It's been two years since the issue was started and poetry is still changing my .zshrc without asking me. The option not to do so is a must.

[finswimmer]

The new installer script install-poetry.py now put's to executable into ~/.local/bin. See the announcement for poetry 1.2.0a1: https://python-poetry.org/blog/announcing-poetry-1.2.0a1/#deprecation-of-the-get-poetrypy-script

So I guess we can close this ticker now :)

Feel free to leave a comment if someone disagree.

fin swimmer

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.