`vendoring` is broken, due to a cyclic dependency during license fetching
See original GitHub issueWell, the lack of maintainance of the license fetching logic in vendoring
has come to bite us. 😃
flit
recently established a cyclic dependency, by depending on tomli
: see https://github.com/takluyver/flit/issues/451 and https://flit.readthedocs.io/en/latest/bootstrap.html.
We get licenses from sdists in vendoring
(which means building metadata / wheels – leading to https://github.com/pradyunsg/vendoring/issues/1). Since flit is no longer bootstrappable through regular mechanisms, it’d be best to switch to using wheels for the license fetch phase.
This is the tracking issue for actually fixing this, and adopting the fix in our workflow.
Issue Analytics
- State:
- Created 2 years ago
- Comments:10 (10 by maintainers)
Top Results From Across the Web
NG0200: Circular dependency in DI detected while ... - Angular
Break this loop (or circle) of dependency to resolve this error. This most commonly means removing or refactoring the dependencies to not be...
Read more >Spring boot application fails to start after upgrading to 2.6.0 ...
If your application fails to start due to a BeanCurrentlyInCreationException you are strongly encouraged to update your configuration to break ...
Read more >Circular dependency warnings after upgrading Angular CLI
I'm using Wijmo 5.20172.334 in an Angular project, and after upgrading my [url=https://github.com/angular/angular-cli]Angular CLI version, ...
Read more >Nixpkgs 22.11 manual - NixOS
The package is thought to be broken, and has had its meta.broken set to true . ... In particular, all build-time dependencies are...
Read more >NetSuite Applications Suite - Handling Dependency Errors
NetSuite Point of Sale (NSPOS) Third Party Licensing ... Circular dependency – The component is part of an interdependent, non-hierarchical cycle.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
backend-path
is working correctly forflit_core
, as far as I’m concerned. It’s set here, and flit_core can be built from source with no problem:The issue arises because flit_core has a runtime dependency (not a build dependency) on tomli. So tomli’s build dependency on flit_core means it has a transitive build dependency on itself. Building flit_core is fine, using it for tomli is what falls down.
Another possible workaround would be to have a special build backend in tomli sdists - e.g. bundling flit_core in the sdists - and using
backend-path
in tomli’s pyproject.toml to use that. That would work, as far as I know, but I don’t think it should be on tomli to do special workarounds for bootstrapping - if we need special cases, they should be in flit_core.Yet another possibility is that pip could detect such a cycle - we’re trying to build tomli, and we’ve found that we need tomli - and use a wheel in an isolated build env to break it, unless you pass some extra option
--no-wheels-not-even-to-break-build-cycles
. But that’s probably a lot of work for a hopefully very specific situation.I don’t particularly mind doing that - but I’d guess that there’s a large overlap between the people who can’t use a pre-built wheel and the people who reject bundled packages, so I don’t know if bundling would help many people.