Skip to content

poetry lock --no-update does not reflect directory packages changes #3783

Closed

Description

@skovhus
  • I am on the latest Poetry version.
  • I have searched the issues of this repo and believe that this is not a duplicate.
  • If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).
  • OS version and name: MacOS 10.15.7
  • Poetry version: 1.1.5

Issue

When using packages with the directory source type, I would expect that running poetry lock --no-update inside the package would update the poetry.lock file with changes for all directory packages being used.

The issue can be reproduced with:

poetry new lib
poetry new project

# project depends on lib (directory package)
cd project && poetry add ../lib

# lib is updated with a new dependency
cd ../lib && poetry add arrow

# we try to update the project with --no-update (we do not want to run poetry update that will update too much)
cd ../project
poetry lock --no-update

# the lock file is not updated correctly
grep arrow poetry.lock  # lock file is not updated

To my knowledge the only workaround are:

  1. poetry update (which naturally updates more than we want here – i.e. unrelated dependencies)
  2. poetry update <dir_package1> <dir_package2>... (cumbersome if you have a lot of directory packages – especially painful in a big mono repository)

I believe the suggested behavior makes sense for both editable and non-editable directory packages.

Activity

  1. added
    kind/bugSomething isn't working as expected
    status/triageThis issue needs to be triaged
    on Mar 13, 2021
  2. skovhus commented on Mar 13, 2021

    @skovhus
    Author

    I had a look at fixing this. It might be an option to change the _solve function to something like this:

    diff --git a/poetry/puzzle/solver.py b/poetry/puzzle/solver.py
    index 7465df1b..fe3f26fd 100644
    --- a/poetry/puzzle/solver.py
    +++ b/poetry/puzzle/solver.py
    @@ -245,9 +245,14 @@ class Solver:
             if self._provider._overrides:
                 self._overrides.append(self._provider._overrides)
     
    +        if use_latest is None:
    +            use_latest = []
    +
             locked = {}
             for package in self._locked.packages:
                 locked[package.name] = DependencyPackage(package.to_dependency(), package)
    +            if package.source_type == "directory":
    +                # NOTE: we could be less strict here and only append these in case the use didn't
    +                # specify any `use_latest` packages. That means that `poetry update arrow` will not
    +                # pull in directory package changes.
    +                use_latest.append(package.name)
     
             try:
                 result = resolve_version(

    Let me know if there are better solutions to this. I would like to create a PR to fix this issue. :)

    I see that the code snippet doesn't cover poetry lock --check. I'm wondering if the locker needs to change instead of the solver. I will investigate further.

  3. skovhus commented on Oct 30, 2022

    @skovhus
    Author

    Yay! FYI @madsnedergaard @FelixDQ not sure if we still have the poetry update script, but it seems some of it can be removed with the next Poetry version.

  4. added
    area/solverRelated to the dependency resolver
    kind/enhancementNot a bug or feature, but improves usability or performance
    and removed
    kind/bugSomething isn't working as expected
    status/triageThis issue needs to be triaged
    on Oct 30, 2022
  5. madsnedergaard commented on Oct 31, 2022

    @madsnedergaard

    Yay! FYI @madsnedergaard @FelixDQ not sure if we still have the poetry update script, but it seems some of it can be removed with the next Poetry version.

    Hurray, thanks for the ping! ❤️ And thanks @adriangb for fixing it! 👏

  6. github-actions commented on Mar 1, 2024

    @github-actions

    This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

  7. locked as resolved and limited conversation to collaborators on Mar 1, 2024
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

    area/solverRelated to the dependency resolverkind/enhancementNot a bug or feature, but improves usability or performance

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions