Have the poetry show --outdated result reflected in its exit code for automation/CI

[rhtenhove]

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.

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 of docker installed:

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.

[agoblet]

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]

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-run and 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]

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]

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.

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:

poetry/src/poetry/console/commands/show.py

Lines 261 to 265 in b91531e

	color = "green"
	if update_status == "semver-safe-update":
	color = "red"
	elif update_status == "update-possible":
	color = "yellow"

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]

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]

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]

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 lock

[agoblet]

That sounds good indeed. So a PR would then consist of

• add boolean --exit-code option to poetry lock and poetry update commands, which are false by default
• When this flag is set to true, the exit code of the commands will be dependent on the outcome:
  • if packages are updated, exit code will be 1
  • in case of a dry run, if packages WOULD BE updated, the exit code will be 1
  • if the lock file is updated, the exit code will be 1
  • if everything is up to date, the exit code will be 0

@radoering do you agree?

[radoering]

In my opinion, that sounds reasonable. However, I think opinions of other core members on this flag are required.

[FredHappyface]

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)