-
Notifications
You must be signed in to change notification settings - Fork 140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: cyclic dependency with tomli==1.2.1
and flit_core==3.2.0
#451
Comments
Companion ticket: hukkin/tomli#130 |
Have a look at the bootstrapping page in the docs. My assumption is that most 'normal' users will use pre-built wheels - at least of some of these initial packages - and thus avoid the situation. If you need to build everything from tarballs - e.g. to populate another packaging system, then you need a little bit of manual intervention, and that's what the bootstrapping document is about. |
I agree, my use case is not that of a normal user. But even bootstrapping does not help: hukkin/tomli#130 (comment) This actually broke the release-pipeline for a product in maintenance. Manual intervention was difficult but possible. Lockfiles don't help here, as My only wish is for a little stricter dependency constraints so this does not happen again. Feel free to close. |
I think ultimately the fix for this will be to have a TOML parser in the Python standard library. As things stand, we've standardised the TOML format for packaging, but we need a third party package to parse it. Tomli's packaging information is in a TOML file, so it needs a TOML parser to build it. But adding to the standard library is slow and contentious, so we'll have to live with that for a while. |
Wanted to just add here that we also have a release pipeline that was broken with this release - pathway forward to "fix" the issue is clear but wanted to flag it, exact same issue as described by @lummax |
FWIW, this has broken pip's own vendoring processes. It's probably fine, since those processes need some TLC anyway -- it's worth flagging, but I don't think that changes anything. :) |
Hello - we are using GCP Dataflow using python and we are seeing an error that is precisely related to this cyclic dependency. This breaks us unfortunately - and it is not easy for us to change the way it wants to run (because this is GCP's code and not our code). |
Can I ask you (or anyone) to investigate in a bit more detail what GCP dataflow is actually trying to do? I've never used it. |
We are using Dataflow's Flex Templates (https://cloud.google.com/dataflow/docs/guides/templates/using-flex-templates) When the Dataflow job kicks off, the Apache beam program runs and it starts off by installing some python packages. This is where we are seeing the error - and it exits. This started failing yesterday, which coincided with the new flit_core release. Also, the log message below indicates the problem. A lot of these packages are required - and not specified by code in my control. Anything you can do would be much appreciated - thanks!
|
The pip command that it used to kick off the installation:
|
Looks like if you use a version of pip < 21.x , installs get hosed. pip 19 yells at you about not supporting
pip 20 - not so much (as seen in the above comment ) - it tries and fails. pip>=21 has no issue. Upgrading the pip version resolves the dataflow flex-template issue. |
Thanks! Quite a bit has changed in pip & packaging tools in the last couple of years - pip uses calendar versioning, so 19.x means released in 2019. I see that people are 👍-ing @juannyG's comment, which looks like consensus that the issue specifically on GCP Dataflow is solved (or worked around :-) by upgrading pip. If that's not the case - if this is still a problem for some of you using GCP Dataflow even after upgrading to the newest pip, please do say. I don't really have a good way to fix this, so I'm not promising anything. But having a sense of how many people are affected and how big an inconvenience it is might help to figure out whether a workaround of some kind is needed. |
I am running into a similar issue here. I am trying to install salt on MacOs through brew. This is where it is failing at the moment. It does look like I am using pip 21.0+
|
For most purposes - if you're just trying to get stuff installed and working - using If you want to build specific packages from source (normally those with compiled extensions), specify those like The one case I'm aware of where people really want to avoid downloading wheels is when making packages for other packaging systems - Linux distributions, Spack, etc. If there's another scenario where this is important, let me know. These people will need a bit of manual fiddling as described in the bootstrapping page to get Tomli set up. There is no really good way to avoid this until & unless a TOML parser is added to the Python standard library. |
Any thoughts on changing Tomli's build backend from flit_core to poetry_core? Poetry_core already bundles a TOML parser so I assume packagers who can't accept that already have a process in place for unbundling. I couldn't find any issues regarding this in Poetry's or Poetry-core's issue tracker so I get the feeling that unbundling may be less of a nuisance for packagers than bootstrapping using a source copy of a TOML parser. The latter has resulted in issues created on flit's and tomli's issue trackers, and some packagers (at least gentoo, arch, macports) setting up custom setup.py files and refusing to build Tomli using PEP517. The lack of a standard library TOML parser is admittedly annoying, and means packagers need to either accept a bundled parser or set up a temporary one for the bootstrapping process. Maybe it's best if we make it easy on them by ensuring they only need to do this with one build backend (i.e. poetry_core) instead of all of them? There's also the chance that I'm missing something critical or that this will only lead to these same issues being opened on poetry_core's issue tracker instead 😄 EDIT: Regarding my the last paragraph: if these packagers need e.g. the pypa/build tool (also depends on Tomli), then what I suggested probably won't help at all. But yeah I'm no packager so have limited knowledge of their required tools and processes. |
I believe that the packaging ecosystems that are strict about building everything from source also tend to strongly object to bundling, so I don't think a solution that relies on bundling a TOML parser in the build backend will make them happy. Even if they have streamlined unbundling in general, unbundling in this case just puts you back in the same dependency cycle (whether that's flit_core <-> tomli, or poetry_core <-> tomlkit). So it's going to need some kind of special intervention. Maybe I'm wrong about this, though. 🙂 If there are significant use cases where people need to install from source but are fine with bundled dependencies, we can do that (either rely on Poetry, or bundle tomli in flit_core sdists). My impression is that a lot of the people having issues don't actually need to build everything from source, but are doing that as a convenient shorthand for building something from source. It would be nice if pip had better ways to control this (e.g. 'build from source anything that involves native code' - but I don't think that's knowable ahead of time.) |
Yeah agreed. However, my theory was that maybe we can reduce the number of build backends where this special intervention is required to exactly one. And if yes, maybe it's the pragmatic thing to do? |
We could do, but poetry-core bundles quite a few packages, so it doesn't seem like the best starting point for bootstrapping. And if you unbundle those, some of them are built with setuptools, so we'd be chaining back to setuptools again, which I'd like to demonstrate isn't necessary. And setuptools has its own cycle if you use the PEP 517 APIs (setuptools <-> wheel). Another option is that we could make a special backend to build tomli (either in import sys
sys.path.insert(0, '.')
from flit_core.buildapi import * That would have the same effect as the manual workaround I've suggested for downstream packagers. But it wouldn't solve the issues people are having using pip, because flit_core would still have a dependency on tomli. |
Should build move to flit (see pypa/build#394), then to bootstrap Python you would only need five packages: flit_core, tomli, pep517, build and installer. If tomli switches to poetry-core, that's going to balloon to at least fourteen, not counting their build dependencies, assuming unbundling. |
When building python dependencies with `pip install --no-binary :all:...`, we run into a bug caused by a cyclic dependency with `tomli==1.2.1` and `flit_core==3.2.0` while building dependencies of setuptools_scm. Apparently, it works with `pip >= 0.21` according to pypa/flit#451 (comment)
When building python dependencies with `pip install --no-binary :all:...`, we run into a bug caused by a cyclic dependency with `tomli==1.2.1` and `flit_core==3.2.0` while building dependencies of setuptools_scm. Apparently, it works with `pip >= 0.21` according to pypa/flit#451 (comment)
After
And changed my pip commands to use pip3.8 as only that one resulted in pip 21.x being used. And only then the cyclic dependency problem was fixed for me. |
If you've got multiple |
I'm going to close this now. Two things have happened to mitigate the cyclic dependency:
That still leaves a problem to be solved for downstreams using Python 3.10 or older with a rigid rule of removing bundled dependencies - sorry about that. But I assume they have by now figured out some kind of workaround, however ugly, and it can be cleaned up as they update their Python version. So I don't think there's anything more to do here. |
I can not download
tomli
because there is a cyclic dependency withflit_core
.Reproducer:
Example output:
The text was updated successfully, but these errors were encountered: