Is it possible to update only one package and its dependencies?

[mogoh]

Hello,

I just had some problems with pipenv and thought about switching to poetry.

The problem, I would like to solve

Let's say I have two packages:

package-a
package-b

package-a has dependency dep-a
and package-b has dependency dep-b

Now I want to update package-a and dep-a without updating dep-b, not even a minor version.

A concrete example

I have this packages.

[tool.poetry.dependencies]
django = "==2.2.18"
django-cms = "==3.7.4"

poetry.lock has for example:
django-treebeard = ">=4.3"

I want to be able to update django to version 2.2.19 without updating treebeard. Treebeard 4.5 introduced a bug that could broke the database. If I update django, I don't want to worry about that kind of problems.

To my knowledge, this is not easy possible in pipenv. Is this possible in poetry?

[mogoh]

Would this do the desired behavior?

poetry add django@2.2.19

[tbrlpld]

I keep running into this problem and this thread too. It seems like an odd behavior for poetry to update unrelated packages.

[lachaib]

Hi, just came this thread
What worked for me was poetry add ddtrace==1.7.3 to upgrade ddtrace package.
I hope this helps

[zachliu]

what version of poetry are you using? in my case poetry 1.4.2 doesn't seem to allow this:

poetry add <pkg>==<latest version>

Because <your repo> depends on both <pkg> (<previous version>) and <pkg> (<latest version>), version solving failed.

[lachaib]

Seems like I'm still on 1.2.2 😖

[surya-sigtech]

@zachliu Did you find any solution for error you mentioned here?

[finswimmer]

Hello @mogoh,

whenever you update a direct dependency, poetry needs to rebuild the dependency tree. This can lead to updating other packages as well within the range of version given in the pyproject.toml.

In your case, you want to keep a dependency of a dependency at a specific version. IMO it is legal that you directly depend on this dependency. So I would suggest you add it to your pyproject.toml and pinn it to the desired version, or of applicable say it must be smaller then the version with the bug.

fin swimmer

[mogoh]

I would like to separate the thing I want from the things I need.
When I pin down dependencies, I mix that, which is undesired.

In the old workflow with only pip and pip freeze I had all the packages I want in requirements.txt and all I need in requirements.freeze. If I updated a package, I could be sure to hold back all other updates. Is this not possible with poetry?

whenever you update a direct dependency, poetry needs to rebuild the dependency tree.

Is the same true if I add a direct dependency?

[ZelphirKaltstahl]

Would it be an OK solution for you to put a comment in your pyproject.toml file, which separates "what you want" from "what you need to specify to get the desired result"?

[mogoh]

It is better then nothing, but ideally I would pin all secondary dependencies.
That would be very tedious.
I know it sounds a bit paranoid, because a minor update of secondary dependencies should not break anything, but sadly it does happen.

[pdecat]

Another case where only updating a single package is desired is when upgrading a --dev dependency, it currently also updates all runtime dependencies.

[steve-mavens]

@mogoh What I do is the same as what I do when I add a brand new dependency but don't want to update everything: edit the pyproject.toml to add the new requirement (so in your case this could be django = "^2.2.19" or django = "2.2.19", or something else, depending on exactly why you're upgrading that package now). Then do poetry lock --no-update, which solves the environment again but doesn't update anything unnecessarily. I expect this is pretty much what poetry add is doing too, but personally I find it easier to remember what the behaviour is when I'm explicitly saying "don't update". Finally install from the new lock file.

Sometimes it's a bit tedious having to look up the new version number I want, but usually by the time I've figured out that something needs updating (due to a security advisory or whatever), I also know what minimum version I now need. I guess another trick would be to set the requirement to >2.2.18, which if 2.2.18 is the version you currently have will mean "get me the latest consistent with the rest of my environment". Then once you've locked and installed you could (if desired) do "poetry show django" and change the pin again to whatever that latest version turned out to be.

[tbrlpld]

I just tried this and now still get the unrelated dependency that is being updated 🤔 Is this something that has changed?

[UncleGoogle]

are you sure it is unrelated? --no-update doesn't touch packages in valid ranges, but something the whole deps tree require to update package "C" if you update "A". For example having A=1.1.1, B=2.3.1 in pyproject.toml (where B requires C in range >2,<4) when manually change A to updated version A=^1.2.2 (where A since version 1.2 requires C>3), then you can see that C in lock was updated from 2.x to version 3.x, to be compliant with new version of A.

[thibaudcolas]

For people needing this – #3248 proposes to change poetry lock so it works like this by default (rather than needing --no-update).

[ababic]

I'm not sure if this option was available when the original question was asked. But, to update Django only (following your version rule pyproject.toml), I suspect what you want is:

poetry update django

The trick here is to use poetry's 'loose pinning' options to specify what you are happy with. If you specify exact versions of everything in pyproject.toml, running the above won't change anything.

For dependencies that follow sematic versioning, I would normally use something like this in pyproject.toml:

django = '~3.2.20' 

With this, poetry update django would pick up any new patch versions (e.g 3.2.21, but not new minor or major versions)

Where the dependency has a good reputation for not introducing breaking changes in minor versions, I might even go with:

django = '~3.2' 

With this, poetry update django would pick up minor version updates too (e.g.3.3).

However, the looser the pinning, the more cautious you need to be when committing the result of poetry update (without specifying any specific dependencies). Without a minimum patch version specified (e.g. ~3.2.20), it would be possible for another dependency to specify an earlier version of Django than we are really happy with (e.g. django = 3.2.17) - in which case, you may miss out on critical patches. Usually, package maintainers know not to do this, but it IS possible. So, probably only a viable approach for projects with capacity to review upgrade PRs before merging.

[ayushi-singhal]

Hey I have faced one issue related to Flower and Tornado

I need to update Tornado lib version(in requirements.txt) via flower lib version(in requirements.in).
I have updated flower version and ran cmds pip-compile --output-file requirements.txt requirements.in and pip install -r packages/shared/requirements/requirements.txt. But I do not see tornado version getting upgraded.

What steps am I missing here?

[dimbleby]

pip-compile ..., pip install ...

What steps am I missing here?

you are in the wrong place, what you are doing is unrelated to poetry

[ayushi-singhal]

I read about pipenv and poetry for managing project dependencies, therefore, posted here for a clue.

I have tried the commands for pip-compile and pip install but transitive dependency version is not changing. I appreciate the help here.
This will resolve my long pending task.

Thanks!

[ayushi-singhal]

I am only changing requirements.in file, assuming one should not change requirements.txt file

[dimbleby]

this is the poetry discussion board: you are in the wrong place. if you need help with pip-compile and pip, you should look for resources provided by those projects.

[ayushi-singhal]

Thanks.