Unable to export a package with a circular dependency

[neersighted]

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).

[dimbleby]

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]

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]

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]

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]

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).

And a testcase would be good of course.

[brechtm]

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.

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.

[dimbleby]

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.

[brechtm]

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.