An option to run full composite despite to errors

[mganisin]

New option introduced that changes the behavior of composite script to executes all the scripts despite to present errors. Exit code is sum of all the codes. The name of the option 'keep_going' is inspired/reused from 'GNU make' with similar/same purpose.

Pull Request Checklist

• A news fragment is added in news/ describing what is new.
• Test cases added for changed code.

Describe what you have changed in this PR.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (1c5bd6a) 84.79% compared to head (c6eb5f4) 84.80%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2582   +/-   ##
=======================================
  Coverage   84.79%   84.80%           
=======================================
  Files         104      104           
  Lines       10387    10390    +3     
  Branches     2272     2273    +1     
=======================================
+ Hits         8808     8811    +3     
  Misses       1105     1105           
  Partials      474      474           

Flag	Coverage Δ
unittests	84.59% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[frostming]

What is the meaning of sum of the return code, if more than one processes return non-zero?

[mganisin]

Well, the expectation (mine expectation) is that composite will fail in case of a failure. Only change is that it will run all the "sobcommands", so non-zero code is needed. And so far I believe the exact value of the code does not matter that much, so I chose to do a sum. Anyway any value, even fixed should be appropriate, just the indication that something has failed (non-zero exit code) should remain.

In theory, if all the "subcommands" will fail with code 1 (or any other known value), then yes, I was also thinking that it could be useful information to preserve it somehow in the composite_code, therefore sum. Honestly I do not assume that this can have real use, but still there.

[frostming]

I am not going to accept this patch because I don't think this requirement has been carefully considered.
There may be many different situations here, each corresponding to a user case.

1. People want to ignore errors for specific steps, but fail fast for others
2. People want to continue on errors, but the return code should be equal to what the second step returns. As long as the second step succeeds, the whole task should succeed.

While your patch only cover a small part of all use cases, yes, your use case, it will bring more confusion compared to not supporting at all. The scope of a feature may be larger than you'd think, large enough that I think it goes beyond the responsibilities of PDM. As a workaround, you can either:

1. Make a script wrapper that ignores errors for specific commands and return whatever code as you want.
2. Seek for help in a dedicated task orchestrator

PDM is never built to be an all-in-one tool, we choose to not support some features, leaving the flexibility to users.

[mganisin]

Correct, this covers only an existing use case that I am aware of. Actually it might be rather bad idea if I was implementing a solution for use cases that I am not aware of as the outcome wouldn't be optimal.

This proposal doesn't seem to be in conflict with use cases you outlined.

For example anyone interested in case #1 could suggest/implement another option like 'ignore_errors' (again inspiration for name from 'make') for individual scripts and that would lead to pretty versatile solution yet included in pdm out of the box. (if ever needed, maybe in such case it would make sense to implement ignoring errors directly in the script; I can't say this is not my use case)

Case #2 really sounds to me like dependency execution (like 'make' or other pipeline managers do) and I understand, that is not in scope of pdm. Neither this my PR suggests anything similar, I don't consider my proposal to be a scope changer.

I understand that there can be many other 'unspoken' and uncovered use cases, however the development should not be stopped by possible conflicts with unknowns, should be?

Of course, plenty of solutions outside of pdm already exist, actually neither 'composite' is needed. But it is there luckily and it is very helpful. It can be even better with this small change.

I can think of returned code, current sum doesn't seem to be optimal actually. I think fixed value or code of last failure would be much better.

I'd like to ask you kindly to reconsider your decision again. I agree this does solve only my requirement, on the other hand I believe that it is fair. The 'composite' feature when implemented also solved only someone's requirement, at the end is useful for everyone. Furthermore as mentioned I think this neither conflicts with anything nor introduces any sign of complexity.

Thank You for your time spent on my PR in any case.

[pawamoy]

I'd suggest following what Bash's pipefail option does: returning 0 if all commands returned 0, or the exit code of the last command (rightmost) that failed.

If set, the return value of a pipeline is the value of the last (rightmost) command to exit with a non-zero status, or zero if all commands in the pipeline exit successfully. This option is disabled by default.

IMO summing exit codes is not only confusing, it can even be wrong: if all exit codes reach 256 together, then your exit code will be modded to 0!

% bash -c 'exit 256'; echo $?
0
% bash -c 'exit 257'; echo $?
1

[mganisin]

I updated this PR to return rather the code of last failed job in case of failure.