consider pipx as installation method

[cs01]

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

Issue

pipx is a new project I started that replaces pipsi. pipsi is great but development and support has stopped, so I started pipx with the goal of using modern Python (venv's only, Python 3.6+), improving the UX, adding new commands, and adding an option to run applications in one-time environments that are deleted after exit.

pipx installs poetry nicely and might be a good alternate way to recommend poetry be installed.

Attached is a short video demonstrating its installation.

https://github.com/cs01/pipx

[gonvaled]

This seems to be working for me. The official install method fails in Linux Mint 19 Tara

[batisteo]

Is your proposition is to replace

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

by

curl https://raw.githubusercontent.com/cs01/pipx/master/get-pipx.py | python3
pipx install poetry

❓

[cs01]

IMO it makes sense to let poetry stop worrying about maintaining custom installers and let pipx focus on that. So long term I think replacing is the right choice.

This means

poetry self:update

will turn into

pipx upgrade poetry

and to install a specific version,

pipx upgrade poetry --spec poetry==0.12.5

The poetry self:update --preview option would need to be replaced with something like

pipx upgrade poetry --spec git+https://github.com/sdispater/poetry.git@develop

The preview option will only work once pip has support for PEP 517 added (it currently fails with this command because it is hardcoded to install by cloning the git repo, then running setup.py rather than being flexible enough to be told to clone and run poetry install).

Unless @sdispater or others feel it is generally more reliable than the recommended installation method (as @gonvaled indicated), I am currently suggesting that it is added alongside the pipsi instructions.

[sdispater]

@cs01 I'd gladly review and merge a PR that adds (or replace pipsi) pipx to the documentation. However it's unlikely that it will replace the recommended installer. Here are a few reasons:

• The installer installs Poetry in such a way that it is completely isolated from the rest of the system (vendored dependencies). That way its dependencies are fixed and there is no risk of dependencies being removed or updated by the installation of another tool. I know pipx installs in a virtualenv but this is not the same thing as having a fixed set of dependencies.
• If you install it via pipx (like with pip), Poetry will only be aware of the Python executable it has been installed for and as such will not be able to pick up the proper python version set by a tool like pyenv. Let's say I execute pipx install poetry for pipx installed for Python 3.7.1, the poetry command will be linked with Python 3.7.1. So if I later do pyenv shell 3.6, poetry will still see Python 3.7.1.

[bersace]

Note that poetry is incompatible with docker-compose. They conflict on jsonschema version. That's a good reason to have poetry in it's own venv. I just wished .poetry was in .local or .cache because i don't like to clutter my home.

[batisteo]

Now I really have the feeling that a Python packaging/dependency manager shouldn’t be written in Python… 😞

[funkyfuture]

Note that poetry is incompatible with docker-compose. They conflict on jsonschema version. That's a good reason to have poetry in it's own venv. I just wished .poetry was in .local or .cache because i don't like to clutter my home.

well, you'd have to install Docker-Compose w/ pipx.

[RoelantStegmann]

If you install it via pipx (like with pip), Poetry will only be aware of the Python executable it has been installed for and as such will not be able to pick up the proper python version set by a tool like pyenv. Let's say I execute pipx install poetry for pipx installed for Python 3.7.1, the poetry command will be linked with Python 3.7.1. So if I later do pyenv shell 3.6, poetry will still see Python 3.7.1.

Yes, I had this issue. It is sad, because installing poetry in each conda env feels like overdoing it.

[fgervais]

@sdispater does the pipx installation still have the above-mentioned shortcomings compared to the new install-poetry.py script?

Since install-poetry.py uses virtualenv and pip now I guess poetry has a way to mitigate previous concerns related to pipx and the isolation?

[shelper]

@cs01 I'd gladly review and merge a PR that adds (or replace pipsi) pipx to the documentation. However it's unlikely that it will replace the recommended installer. Here are a few reasons:

• The installer installs Poetry in such a way that it is completely isolated from the rest of the system (vendored dependencies). That way its dependencies are fixed and there is no risk of dependencies being removed or updated by the installation of another tool. I know pipx installs in a virtualenv but this is not the same thing as having a fixed set of dependencies.
• If you install it via pipx (like with pip), Poetry will only be aware of the Python executable it has been installed for and as such will not be able to pick up the proper python version set by a tool like pyenv. Let's say I execute pipx install poetry for pipx installed for Python 3.7.1, the poetry command will be linked with Python 3.7.1. So if I later do pyenv shell 3.6, poetry will still see Python 3.7.1.

well then if i use the https://raw.githubusercontent.com/python-poetry/poetry/master/install-poetry.py to install poetry, then my poetry is linked to whatever the python version that runs this script. so poetry is linked to this python version anyway, i dont see how this is different from using pipx...
anyway just a comment, maybe i missed something, but either way, poetry should be installed by the new installation script

[wtfzambo]

@cs01 I'd gladly review and merge a PR that adds (or replace pipsi) pipx to the documentation. However it's unlikely that it will replace the recommended installer. Here are a few reasons:

• The installer installs Poetry in such a way that it is completely isolated from the rest of the system (vendored dependencies). That way its dependencies are fixed and there is no risk of dependencies being removed or updated by the installation of another tool. I know pipx installs in a virtualenv but this is not the same thing as having a fixed set of dependencies.
• If you install it via pipx (like with pip), Poetry will only be aware of the Python executable it has been installed for and as such will not be able to pick up the proper python version set by a tool like pyenv. Let's say I execute pipx install poetry for pipx installed for Python 3.7.1, the poetry command will be linked with Python 3.7.1. So if I later do pyenv shell 3.6, poetry will still see Python 3.7.1.

well then if i use the https://raw.githubusercontent.com/python-poetry/poetry/master/install-poetry.py to install poetry, then my poetry is linked to whatever the python version that runs this script. so poetry is linked to this python version anyway, i dont see how this is different from using pipx... anyway just a comment, maybe i missed something, but either way, poetry should be installed by the new installation script

For me is exactly the same. Tested both in windows and linux, poetry is tied to the python version it's been used to install it.

The only way I found to specify a different one when creating a virtual environment is to run poetry env use your_python_version_here. Activating it (with pyenv or scoop) when running poetry new or poetry init doesn't seem to do anything.

[namanrawal47]

The best way to install poetry using pipx today is:
pipx install poetry==1.2.2

[github-actions]

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.