Can not install any poetry based project with pip from source distribution
See original GitHub issue-
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.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:8
- Comments:23 (8 by maintainers)
Top GitHub Comments
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):