-
The official documentation warns not to. But should I? I see that these projects are pip installing poetry: https://github.com/PyCQA/isort/blob/f074239e5e39c2dd9e4d373e3c6ce528dae3f78c/Dockerfile#L5
how can that happen ? my application/library, and its dependencies will be installed in a virtual env, but poetry is installed at user level (outside of any virtual env) if, in my user level, I have no other python packages to worry about (like in a Docker container, or a github action), then can I pip install poetry ? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
It really depends on your use case. If this is for your workstation, I would generally advice using either the If you are installing poetry on an ephemeral CI environment or in a container, installing to the system-site might cause minimal side-effects and should be okay. But my advice in these scenarios (or well any scenario), is to ensure that you do not disable virtual environment creation in poetry (even in a container). This would mean that when you run a poetry command for a project, a new virtual environment will be created if one does not already exist, ensuring that the project's dependencies are isolated and clean. If you choose not to use virtual environments, you can end up in a scenario where poetry will decide to remove unused dependencies or upgrade dependencies leaving you with a broken system-site when managing dependencies for a project. But all in all, poetry is a tool. It is upto you to use it in a way that makes sense for you. |
Beta Was this translation helpful? Give feedback.
It really depends on your use case.
If this is for your workstation, I would generally advice using either the
install-poetry.py
script, orpipx
(personal favorite). The rationale for this is that when using your system-site (or user-site), you are installing dependencies along with the package into a shared site, this means installing package A (1.0.2) might install package B (1.0.0); and then later installing package C (3.0.0) might install package B (0.5.0) because it is not compatible with B (1.0.0). This might cause package A to fail. These sort of conflicts are more common in longer lived and/or shard purpose environments; like developer machines. This ensures poetry does nto break …