Skip to content

Unable to export a package with a circular dependency #118

Closed

Description

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

Activity

  1. dimbleby commented on Sep 7, 2022

    @dimbleby
    Contributor

    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.

  2. neersighted commented on Sep 7, 2022

    @neersighted
    MemberAuthor

    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.

  3. brechtm commented on Sep 15, 2022

    @brechtm
    Contributor

    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.

  4. dimbleby commented on Sep 15, 2022

    @dimbleby
    Contributor

    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.

  5. dimbleby commented on Sep 15, 2022

    @dimbleby
    Contributor

    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.

  6. brechtm commented on Sep 16, 2022

    @brechtm
    Contributor

    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.

  7. dimbleby commented on Sep 16, 2022

    @dimbleby
    Contributor

    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.

  8. added a commit that references this issue on Sep 16, 2022
    2a87128
  9. brechtm commented on Sep 16, 2022

    @brechtm
    Contributor

    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.

  10. added 2 commits that reference this issue on Dec 7, 2022
    ab3a285
    9f64222
  11. added a commit that references this issue on Jan 6, 2023
    f61fa9f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions