Poetry: Allow specifying --user during installation of poetry

Created on 23 Jun 2018  Â·  5Comments  Â·  Source: python-poetry/poetry

On Gentoo, pip installation is recommended/enforced only with --user option:

python3 get-poetry.py          
Retrieving metadata

Installing version: 0.10.3
  - Getting dependencies
  - Vendorizing dependencies
  - Installing poetry
An error has occured: Command '('/usr/lib/python-exec/python3.6/python3', '-m', 'pip', 'install', '--upgrade', '--no-deps', '/tmp/poetry-installer-hz3pap_8/poetry-0.10.3-py2.py3-none-any.whl')' returned non-zero exit status 1.
ERROR: (Gentoo) Please run pip with the --user option to avoid breaking python-exec

As a workaround, I can use pip3 install --user poetry. However, the same issue will resurface if I use

> poetry self:update --preview
Updating to 0.11.0a4
  - Getting dependencies
  - Vendorizing dependencies
  - Updating poetry

 [CalledProcessError]                                                                                                   

 An error has occured: Command '['/usr/bin/pip', 'install', '--upgrade', '--no-deps', '/tmp/poetry-update-              
 rryjj9s1/poetry-0.11.0a4-py2.py3-none-any.whl']' returned non-zero exit status 1.                                      

 ERROR: (Gentoo) Please run pip with the --user option to avoid breaking python-exec

Hence, would be great to have

  • an option to specify --user while installing poetry
  • let poetry register that it was installed using --user and keep the updates using the same option

Most helpful comment

Oh. I see:

Poetry provides a custom installer that will install poetry isolated from the rest of your system by vendorizing its dependencies.

Well, that's a non-starter. In Gentoo Land, dependencies are always shared in common at the system level. Doing so substantially reduces attack surface and guarantees reproducibility across downstream consumers. Where exceptions exist (e.g., bundled Firefox libs), they do so only of absolute necessity. It's unlikely that poetry satisfies that hard requirement.

Packaging poetry for Gentoo means circumventing get-poetry.py entirely, which means manually:

  1. Removing all vendorized dependencies.
  2. Replacing all vendorized dependencies with... something. Possibly import machinery or sys.modules hackery; possibly symlinks to existing system dependencies; possibly something unspeakably arcane, draconian, and/or mystifying. Just "Ugh."
  3. Installing all remaining poetry internals via low-level Gentoo eclasses.

It's certainly feasible, albeit annoying and unnecessarily fragile. All of this could have been circumvented by poetry embracing existing build toolchains (e.g., CMake, Meson, Scons, Bazel, distutils) and system dependencies rather than attempting to reinvent the wheel in isolation.

Scons is even pure-Python, assuming that was an overriding concern. distutils is, of course, even more readily accessible in the Python stdlib. There is no shame in leveraging existing build systems known to behave as expected across all requisite platforms and environments. From the system packaging perspective, non-standard build systems don't exactly inspire confidence.

At least I now know why poetry has yet to receive an official Gentoo package. Given the state of the installer, it seems unlikely it ever will, either. This is why we can't have good things, all. :disappointed:

All 5 comments

See #146

Thanks for the reference! Indeed, this PR will solve the issue

The new installer should fix installation errors;

Necrobump: assuming the new installer complies with the Gentoo ecosystem, I'm contemplating adding a poetry 1.0.0a2 ebuild to my third-party Gentoo overlay. It won't quite be official, of course – but some thing is better than no thing.

I'll probably fail horribly and end up doing absolutely nothing. On the offhand chance I actually do succeed, I'll create an announcement issue here on the tracker. Huzzah!

Oh. I see:

Poetry provides a custom installer that will install poetry isolated from the rest of your system by vendorizing its dependencies.

Well, that's a non-starter. In Gentoo Land, dependencies are always shared in common at the system level. Doing so substantially reduces attack surface and guarantees reproducibility across downstream consumers. Where exceptions exist (e.g., bundled Firefox libs), they do so only of absolute necessity. It's unlikely that poetry satisfies that hard requirement.

Packaging poetry for Gentoo means circumventing get-poetry.py entirely, which means manually:

  1. Removing all vendorized dependencies.
  2. Replacing all vendorized dependencies with... something. Possibly import machinery or sys.modules hackery; possibly symlinks to existing system dependencies; possibly something unspeakably arcane, draconian, and/or mystifying. Just "Ugh."
  3. Installing all remaining poetry internals via low-level Gentoo eclasses.

It's certainly feasible, albeit annoying and unnecessarily fragile. All of this could have been circumvented by poetry embracing existing build toolchains (e.g., CMake, Meson, Scons, Bazel, distutils) and system dependencies rather than attempting to reinvent the wheel in isolation.

Scons is even pure-Python, assuming that was an overriding concern. distutils is, of course, even more readily accessible in the Python stdlib. There is no shame in leveraging existing build systems known to behave as expected across all requisite platforms and environments. From the system packaging perspective, non-standard build systems don't exactly inspire confidence.

At least I now know why poetry has yet to receive an official Gentoo package. Given the state of the installer, it seems unlikely it ever will, either. This is why we can't have good things, all. :disappointed:

Was this page helpful?
0 / 5 - 0 ratings