You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Unable to export a package with a circular dependency #118
Poetry 1.2.0 cannot export a project with a cyclic dependency. I'm unsure if this is an exporter or a Poetry issue, or what would be involved in fixing it, as I have not dug into it myself yet.
$ pipx install poetry==1.2.0
$ git clone https://github.com/python-poetry/poetry && cd poetry
$ poetry export -f requirements.txt -o requirements.txt
Dependency walk failed at poetry (>=1.2.0b3,<2.0.0)
Ironically, that version constraint comes from this repository itself (poetry = ^1.2.0b3).
Reacted by Eugene, José Fernández Ramos, Chris Lemke and Kyle King
In general there's no issue with the export code encountering dependencies that it has previously seen, the issue is specifically if it encounters the top-level project again later in the tree.
IMO the export code is right to barf on this and the rest of poetry is wrong to tolerate it and the preferred fix would be to remove the cyclic dependency.
But it would surely be possible to cope with this special case, if necessary.
That was roughly my guess without having looked at the source code. On one hand, I want to break the circular dep. On the other hand, that will be a slightly drawn out process and I would like to be able to export Poetry itself sooner than later.
I'm running into the same issue with my package rinohtype, which specifies a default set of font packages to install (e.g. rinoh-typeface-dejavuserif) which in turn depend on rinohtype. I don't think this is necessarily wrong. For example, some of these font packages could in the future require a minimum version of rinohtype, which should be specified.
In your case it sounds as though the font packages should depend on the rinohtype package, but not the other way round. rinohtype doesn't depend on the font packages, you just find it convenient to group them for installation.
(Strongly analogous to the relationship between poetry and this plugin, if I've understood correctly)
if people want to install both the rinohtype and fonts, they can depend on them both. Or, if you want, you could publish a meta-package, rinohtype-with-default-fonts or something, which depended on both.
If anyone cares about this enough to submit an MR the fix should be to plumb root.name through get_project_dependency_packages, via get_project_dependencies, and into walk_dependencies.
Then we can go if requirement.name == root_package_name: continue (maybe making a log while we're there).
In your case it sounds as though the font packages should depend on the rinohtype package, but not the other way round. rinohtype doesn't depend on the font packages, you just find it convenient to group them for installation.
rinohtype does depend on the font packages since the default stylesheets included with it make use of them. I don't want to include the fonts in the rinohtype package, because they should be upgradable independently. It also keeps rinohtype upgrades small since the same fonts then do not need to be downloaded again if they do not change.
if people want to install both the rinohtype and fonts, they can depend on them both. Or, if you want, you could publish a meta-package, rinohtype-with-default-fonts or something, which depended on both.
That seems very inconvenient.
Perhaps you can explain why this is wrong? I haven't seen any reasoning to support that claim. Note that this works without issue with an older version of poetry.
I mean it's obviously wrong to have a circular dependency, you have no bottom turtle!
Anyway I don't care to argue about it, if you want to submit an MR then I've laid out above how to handle this, and earlier comments on this issue indicate that maintainers would be minded to accept it.
I'm not here to argue either. I'm genuinely interested in learning why circular dependencies would be wrong. It is not at all obvious to me, I'm afraid. It just sounds like a hollow dogmatic statement akin to "circular imports are a sign of bad design".
In any case, I'm glad a fix for this would be accepted. Your suggestion does the trick, but I'll need some more time to figure out how to write a test case.
Activity
dimbleby commentedon Sep 7, 2022
In general there's no issue with the export code encountering dependencies that it has previously seen, the issue is specifically if it encounters the top-level project again later in the tree.
IMO the export code is right to barf on this and the rest of poetry is wrong to tolerate it and the preferred fix would be to remove the cyclic dependency.
But it would surely be possible to cope with this special case, if necessary.
neersighted commentedon Sep 7, 2022
That was roughly my guess without having looked at the source code. On one hand, I want to break the circular dep. On the other hand, that will be a slightly drawn out process and I would like to be able to export Poetry itself sooner than later.
brechtm commentedon Sep 15, 2022
I'm running into the same issue with my package rinohtype, which specifies a default set of font packages to install (e.g. rinoh-typeface-dejavuserif) which in turn depend on rinohtype. I don't think this is necessarily wrong. For example, some of these font packages could in the future require a minimum version of rinohtype, which should be specified.
dimbleby commentedon Sep 15, 2022
oh, it's definitely wrong!
In your case it sounds as though the font packages should depend on the rinohtype package, but not the other way round. rinohtype doesn't depend on the font packages, you just find it convenient to group them for installation.
(Strongly analogous to the relationship between poetry and this plugin, if I've understood correctly)
if people want to install both the rinohtype and fonts, they can depend on them both. Or, if you want, you could publish a meta-package, rinohtype-with-default-fonts or something, which depended on both.
dimbleby commentedon Sep 15, 2022
If anyone cares about this enough to submit an MR the fix should be to plumb
root.namethroughget_project_dependency_packages, viaget_project_dependencies, and intowalk_dependencies.Then we can go
if requirement.name == root_package_name: continue(maybe making a log while we're there).And a testcase would be good of course.
brechtm commentedon Sep 16, 2022
rinohtype does depend on the font packages since the default stylesheets included with it make use of them. I don't want to include the fonts in the rinohtype package, because they should be upgradable independently. It also keeps rinohtype upgrades small since the same fonts then do not need to be downloaded again if they do not change.
That seems very inconvenient.
Perhaps you can explain why this is wrong? I haven't seen any reasoning to support that claim. Note that this works without issue with an older version of poetry.
dimbleby commentedon Sep 16, 2022
I mean it's obviously wrong to have a circular dependency, you have no bottom turtle!
Anyway I don't care to argue about it, if you want to submit an MR then I've laid out above how to handle this, and earlier comments on this issue indicate that maintainers would be minded to accept it.
Handle circular dependency on root package (fix python-poetry#118)
brechtm commentedon Sep 16, 2022
I'm not here to argue either. I'm genuinely interested in learning why circular dependencies would be wrong. It is not at all obvious to me, I'm afraid. It just sounds like a hollow dogmatic statement akin to "circular imports are a sign of bad design".
In any case, I'm glad a fix for this would be accepted. Your suggestion does the trick, but I'll need some more time to figure out how to write a test case.
Handle circular dependency on root package (fix python-poetry#118)
Handle circular dependency on root package (fix python-poetry#118)
Handle circular dependency on root package (fix python-poetry#118)
GitHub Actions: force use of patched poetry-plugin-export
Update dependency poetry to v1.4.0 (#655)