Poetry: Improve the installation of Poetry

[sdispater]

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

Issue

It's common knowledge at this point that using the recommended installer of Poetry can lead to a lot of problems, being permissions issues, different behaviors depending on how Python was installed.

So, before we reach version 1.0 we have to tackle this problem in order to make installing Poetry as painless as possible.

Every proposition made at this point (using pipsi, using sudo) are not satisfying enough to make an intuitive experience.

We should keep using a custom installer, in my opinion, and make it more clever.

For that, I think taking an inspiration in what rustup/Cargo does would be ideal. Basically we would have the following steps:

• Download the latest stable (or pre-release) version of poetry.
• Download all its dependencies in the poetry/_vendor directory.
• Copy it and all extra files in $POETRY_HOME (~/.poetry/ for UNIX systems and %USERPROFILE%/.poetry/ on Windows).
• Updates the PATH automatically in a system-specific way.

The $POETRY_HOME directory would contain two directories:

• lib which would contain the complete poetry package.
• bin which would contain a poetry script that could be called from any currently activated Python executable. This directory would be added to the PATH automatically.

This has many advantages:

• Installing in the user directory makes sure that we have write access.
• One single installation of Poetry necessary that can be used by any Python executable.
• Easier for the self:update command to work thanks to a single possible location.
• The automatic update of the PATH removes the hassle for the end user to do it themselves.

The poetry script in bin/ could look like this on UNIX systems:

#!/usr/bin/env python
import sys
import os

lib = os.path.realpath(os.path.join(os.path.dirname(__file__), "..", "lib"))
sys.path.insert(0, lib)

if __name__ == "__main__":
    from poetry.console import main

    main()

[cauebs]

Your suggestion introduces some other problems:

• People using pyenv won't be able to follow the current suggestion of installing poetry for each Python version. How will poetry know which one to use?
• Changing the PATH is not simple at all. Our best bet would be to add a symlink to somewhere like ~/.local/bin and hope that's in the PATH

Doesn't adding the --user flag in the current installer solve most issues? self:update works, it gets added to the PATH (probably).

[sdispater]

If ~/.poetry/bin is in the path, #!/usr/bin/env python will always pick the currently activated Python executable, so you just have to switch the pyenv activated Python.

On Windows, it's rather easy to change the PATH. On UNIX systems it's a matter of updaing the appropriate shell profile file (.profile). And in the case Poetry can do that automatically we can display a warning to tell the user to update their PATH.

And, if I remember correctly, using --user does not help in switching Python versions since it will install a single instance of Poetry for the current Python version which will be a problem when using pyenv.

[jgirardet]

thanks for opening this issue

On unix, why do you want to create a $POETRY_HOME ? the $HOME/.local directory contains already a bin and a lib and is already in path in many systems. "dot-directory" on unix are for config and data, not for binary and library

I do not understand why you disqualify pipsi. after all, id does all the thing : download dep, "vendorized" it in own venv, install app in home, and add it to path. that's really what we wanna do. The only trouble might be that the current uptodate version has to be installed from master. The project seems very active. I 'm interested in your opinion since many knows pipsi and poetry install will limite to pipsi install poetry. I'm a bit insistent but since it's the way I use poetry and I find very straightforward, I wanted to share my experience

Jimmy

[cauebs]

@jgirardet Don't get me wrong, I myself install poetry throught pipsi. But that cannot be _the_ official installation method. Imagine telling users: "to install poetry, you first install pipsi..."

[jgirardet]

that's why I insist. I use it, you use it, why ? because it makes poetry very easy to install and to update...

putting in doc : "install pipsi first then pipsi install poetry" is not very diffferent than "download a file and use a custom installer".

i'm just pointing it's just reinventing the wheel, and it "could" save some time to sebastien.

If the finale solution is :
curl http://poetryinstall/script.py | python, I think it's also ok. it's just more work.

By the way we have to think the way to uninstall poetry if we install with a custom script. It's very irritating that custom installers not always provide it.

ps : I have no part in pipsi :wink:

[cauebs]

Well, I use it because the current installer is missing the --user flag and I got tired of editing it, to be honest.

By the way we have to think the way to uninstall poetry if we install with a custom script.

Great point. But I think that, if poetry is isolated in its own directory, it should be trivial.

[sdispater]

@jgirardet If you prefer installing Poetry with pipsi that will still possible, so it won't change your workflow.

It's just that installing an external tool just to be able to install Poetry seems unnecessary.

[piotr-dobrogost]

It looks like pipsi is discarded here based on assumption it would need to be installed first. But does it really have to be installed? Couldn't it be run on the fly the same way custom installer is?
Instead of
curl http://poetryinstall/script.py | python
wouldn't something like this
curl http://pipsi/packaged/as/archive/pipsi.zip | python - <some args>
work?
I'm not saying current pipsi can be run this way but maybe it can be modified/packaged to be run this way?

[nackjicholson]

I really like the idea of putting everything in ~/.poetry. That seems very sensible to me.

[Patristo]

@nackjicholson What's your thoughts about using $XDG_CONFIG_HOME $XDG_DATA_HOME?
(These default to $HOME/.config $HOME/.local/share)
I'm not too across the XDG spec adoption, but understand pip is now using it for its pip.conf files.
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

[nackjicholson]

@Patristo That seems a good spot as well.

[anmsh]

Ran into a bit of trouble installing poetry 0.12.5 just now. I wasn't able to run poetry command after installation. I even logged out and rebooted but with no success. I wasn't even able to uninstall with the --uninstall flag properly. I removed it from the .poetry directory and tried again. Same thing, no success.

I found that both .profile and .bash_profile files got this line added to append poetry to the path.

export PATH="$HOME/.poetry/bin:$PATH"

I noticed that .bashrc didn't have this line. I added this line to this file and I was set. Mine is a plain Debian machine, but may be it was configured differently.

Just wanted to get this to your attention.

[jgirardet]

same under mint (ubuntu based)

[cauebs]

That's why I was against manually changing the PATH and still prefer the idea of creating a link somewhere like $HOME/.local/bin.

[sprt]

Just ran into the exact same issue as described by @animeshb, on Ubuntu 16.04. I think Poetry's installation script should edit ~/.bashrc as well, since ~/.profile isn't always read by Bash.

[JesseFarebro]

It would be nice if we could customize POETRY_{HOME,BIN} etc.

The suggestion of @Patristo to adhere to the XDG specification would be ideal. As others have mentioned $HOME/.local/bin is already in the path of a lot of Linux systems these days (in compliance with systemd).
Currently, poetry is one of the only tools polluting my home directory with no easy way to change this behavior. 😛