poetry: Can not install any poetry based project with pip from source distribution
-
I am on the latest Poetry version.
-
I have searched the issues of this repo and believe that this is not a duplicate.
-
If an exception occurs when executing a command, I executed it again in debug mode (
-vvv
option). -
OS version and name: NixOS 18.09
-
Poetry version: –
-
Link of a Gist with the contents of your pyproject.toml file: –
Issue
Hi,
this is not really a bug about how poetry works, but how poetry interacts with other python packaging ecosystem.
While working on a project of mine which uses pip inside (for now) I noticed that we can not install a package called backoff
which in its recent version switched to poetry.
To reproduce the error you simply need to invoke the following command:
$ pip install backoff --no-binary :all:
Above command tries to install packages from source distribution and not from wheel (which is a requirement of my project).
Digging deeper I noticed that problem is that poetry depends on tomlkit which depends on poetry as a build tool.
I would bet that this is a bug of pip and looking at their issue tracker I found the issue being reported there: https://github.com/pypa/pip/issues/5739. If you look closed you will see that also flit
was affected but they solved it by moving their dependencies around a bit.
I’m not sure what a possible solution might be but maybe vendoring of the dependencies might be a solution (eg. like pip does it). Or maybe there is a better way…
This kinda puts poetry (and actually all projects using it) as a blocker for me and prevents me from investigating further into poetry, which I really hope becomes more used in python ecosystem. This is also a reason why I’m posting this issue here, to try to bring attention to this kinds of bugs and to make poetry adoption easier.
In any case, thank you for you work.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 8
- Comments: 24 (5 by maintainers)
The upcoming release should provide a solution for this. With the next release
poetry-core
will become available. Applying the following patch tobackoff
should enable this to work with newerpip
versions. There is a bug inpip==19.1.1
that does not setup the PEP517 environment correctly, hence failing--no-binary :all:
builds. The following fix was verified to work withpip==20.0.2
Note that this uses an alpha release of
poetry-core
.It seems like, in lieu of a fix from pip, poetry needs to do something to solve this issue. The only real solution to me seems like vendoring any of poetry’s dependencies which, in turn, use poetry for their builds. This likely also applies to any transitive dependencies of poetry too, which makes the problem not only more complicated but prone to changing as more packages switch to poetry.
I have found a workaround which works for my use-case, at least for now. I’m building wheels for everything in the poetry.lock during a build. If I pass each of the packages to
--no-binary
except for tomlkit, poetry, and pastel I still get builds from source for everything else. My project doesn’t depend on those packages, they’re only needed for poetry during the build. I imagine this might still end up causing a problem for any build which wants or needs to use--no-binary :all:
and which also depends on any of these 3 packages.Here’s an example of what the (insanely long) command looks like in my case (built by a script):
@cs01 i think that issue you reference to is not really related to this one, except that both show that there are issues with pip and poetry.
The problem is that there is a circular dependency in poetry dependencies (poetry <-> tomlkit) which is usually not a problem since pip (or any other python package management tool) can handle this.
This becomes a problem when you are required to use source distributions (no wheels for me aka
--no-binary :all:
flag) and the fact that pip needs to install a package to inspect its dependencies, that means that it needs to first install build dependencies first.So this is what happens when you run
pip install backoff --no-binary :all:
:I have also been commenting on the pip issue https://github.com/pypa/pip/issues/5739 and thinking more on this and it seems to me like a mis-feature of pip causing this problem (although I could be convinced otherwise if there is documentation saying otherwise) that is requiring source-based installs of build-time dependencies, especially when those dependencies are already installed and available.
In the case of the command I gave above I’m not only running the pip command via poetry, in a poetry created virtualenv, but poetry is itself already installed in that virtualenv, so poetry should be already-available to pip when it comes to building packages that require poetry at build-time.
The same happens when trying to build
pytzdata
from source. So it is not only connected tobackoff
.Dockerfile:
Output:
I am the maintainer of backoff and I am trying figure out if I need to do a workaround on my side or if this is something that I can expect to be fixed upstream.
I believe the issue is that there is a circular dependency: poetry and tomlkit depend on each other at build-time. It is not clear to me if this is a pip bug, or if circular dependencies just aren’t supported when building from source.
I think @garbas is correct that vendoring (probably tomlkit in poetry?) would work around the problem. If there is a possible fix on the pip side, it sounds like it hasn’t happened yet.
Any thoughts on how to address this or if I should be looking for a workaround downstream?