Open rhtenhove opened 3 years ago
agoblet
commented
2 years ago We would love to see this feature as well. We currently do the CI checking with poetry update —dry-run and some lock file diffing, but that’s quite messy.
What are the thoughts of the maintainers regarding this?
radoering
commented
2 years ago Some thoughts about it:
Probably, such a feature would cause poetry show to take significantly more time. Currently, poetry show only has to check if a package is outdated. In order to check if any outdated package can be updated, I don't see another way than locking again in the background (without writing the lock file). Therefore, I think that could be at most an option not the default.
Further, I think it feels weird if a show command returns a non-zero exit code when it shows what it should. It's more like a check, isn't it?
I don't yet have a clear idea what a clean user interface would look like. 🤷♂️
We would love to see this feature as well. We currently do the CI checking with
poetry update —dry-runand some lock file diffing, but that’s quite messy.
If I understand this correctly, you rely on poetry update --dry-run changing the lock file? That's just a bug: #3766
Probably, you can parse the output of the command to check if there are updates or run poetry lock and diff the lock file.
agoblet
commented
2 years ago The Linux diff program shows the differences between 2 files. It returns exit code 1 if there are differences, else 0. We could take inspiration from that for the show —outdated command. Alternatively we could add an —exit-code flag like git diff does. That way we do not cause a breaking change.
Given that the text is currently already showing in red, the color of errors, the error code could make sense.
Regarding your first point about the performance: I do not see the performance problem. Poetry already shows different colors based on the updatability of a package. The only thing we would need to do is “if printed something red then exit code 1”.
For now working with the console output or updated lock file is fine, just a bit cumbersome compared to a single command.
Curious about your thoughts!
radoering
commented
2 years ago The Linux
diffprogram shows the differences between 2 files. It returns exit code 1 if there are differences, else 0. We could take inspiration from that for theshow —outdatedcommand. Alternatively we could add an—exit-codeflag likegit diffdoes. That way we do not cause a breaking change.
Good references. So a non-zero exit code might be ok.
Given that the text is currently already showing in red, the color of errors, the error code could make sense.
Regarding your first point about the performance: I do not see the performance problem. Poetry already shows different colors based on the updatability of a package. The only thing we would need to do is “if printed something red then exit code 1”.
The meaning seems to be different:
If I do not misinterpret the code, the color is red if it's a minor version bump and yellow if it's a major version bump. The color only tells if an update is semver safe. It does not say anything about the update being possible considering all dependencies. Further, even if you can't update to the latest version, an update to a more recent version may still be possible.
agoblet
commented
2 years ago the color is red if it's a minor version bump and yellow if it's a major version bump
Hmm I did not inspect the code. From my personal output and the example from @rhtenhove it seemed like the color is dependent on whether the dependency is constrained by some other dependency. Your snippet seems to be in line with your interpretation. I’ll experiment a bit more with it today.
If you are right, then this feature would indeed add complexity. Maybe it makes more sense to add a similar feature to poetry update instead then?
agoblet
commented
2 years ago I was indeed wrong about the colors of the output. After taking a closer look at our own output, it indeed reflected the code snippet posted above.
Maybe we could adapt poetry update then instead?
radoering
commented
2 years ago Yeah, it might be better to add such an option to poetry update and/or poetry lock. The semantics may even differ:
poetry lock: exit code reflects if dependencies in lock file are updated (== change in lock file)poetry update: exit code reflects if installed dependencies are updated (== change in virtualenv)poetry update --lock probably should be equivalent to poetry lockagoblet
commented
2 years ago That sounds good indeed. So a PR would then consist of
--exit-code option to poetry lock and poetry update commands, which are false by default@radoering do you agree?
radoering
commented
2 years ago In my opinion, that sounds reasonable. However, I think opinions of other core members on this flag are required.
FredHappyface
commented
1 year ago Just curious if there's anything I can use that will work in CICD? Currently happy to maintain a workaround whilst the decision is made here :)
As it stands I've modified https://github.com/FHPythonUtils/CheckRequirements for me to use going forwards (and if anyone else finds it useful)
Feature Request
Poetry has an excellent way of showing packages which are outdated, but are either required to be outdated (as dependencies), or just plain outdated.
For example, here we have poetry installed, which depends on requests, which in turn depends on an outdated
idna. We also have an outdated version ofdockerinstalled:I'd like to be able to distinguish in a CI job if there are any packages outdated that can be updated, by result of a non zero exit code from running
poetry show --outdated. This should then have a zero exit code when dependencies need to stay outdated.This would be very useful in keeping things up to date, without having to do any manual work, and having a CI job keep watch on that for me.