Use predefined exit codes

Metadata

Project: craft-application
Number: #379
Type: issue
State: open
Author: mattculler
Labels: —
Created: 2024-07-09 07:42 PM UTC
Updated: 2025-05-23 05:26 PM UTC
Closed: —

Current evaluation

Use predefined os.EX_* exit codes instead of hardcoded constants; partly done by merged PR #387 (e8651e46), but `128 + signal.SIGINT` in application.py/util/logging.py and bare `return_code = 1` for Parts/Provider errors plus CraftError's default retcode remain.

Suggested action: keep open

Reason: Maintainer lengau triaged this and split off the easy half into merged PR #387 (commit e8651e46), which converted errors.py, application.py, services/remotebuild.py, services/project.py and services/testing.py to os.EX_* constants. The residual scope is still live in the code: `128 + signal.SIGINT` remains inline at craft_application/application.py:444 and craft_application/util/logging.py:65 (lengau explicitly said 'I'll have to think about the 128+blah ones'), `return_code = 1` for PartsError/ProviderError remains at util/logging.py:72 and :77, `CancelFailedError`'s `retcode: int = 1` default is still unexported (errors.py:359), and commands/remote.py still uses `retcode=77, # os.EX_NOPERM` and `return 75 # os.EX_TEMPFAIL`. These are best-practice/pedantic cleanups with no user-facing behaviour change, so they should stay open but are low value; the 128+signal case needs a naming decision, which is why actionability is not higher.

Evaluated by: mr-cal-bot

Impact: 18 Quick Win: 11 Complexity: 15 Confidence: 82 Actionability: 70

Issue body

### What needs to get done In `application.py` (as well as `errors.py` and `services/remotebuild.py`) there are hardcoded constants that refer to `sysexits.h`. These constants are already defined in the python standard library under `os`: https://docs.python.org/3/library/os.html#os.EX_OK More pedantic, less important: `PartsError` and `ProviderError` both exit 1 - whether these are changed to something more distinctive or not, these should be defined publically, so the values can be used in unit tests. `CraftError` exits an overrideable value that it defines internally as defaulting to 1, this can also be exposed for tests. ### Why it needs to get done Using predefined values is better practice than using magic numbers with explanatory comments.

Evaluation history

Date	Model	Scores	Action	Summary
2026-10-02 05:44 PM UTC	stealth/space-bunny-alpha	Impact: 18 Quick Win: 11 Complexity: 15 Confidence: 82 Actionability: 70	keep open	Use predefined os.EX_* exit codes instead of hardcoded constants; partly done by merged PR #387 (e8651e46), but `128 + signal.SIGINT` in application.py/util/logging.py and bare `return_code = 1` for Parts/Provider errors plus CraftError's default retcode remain.
2026-09-21 08:27 AM UTC	qwen/qwen3.6-35b-a3b	Impact: 30 Quick Win: 17 Complexity: 20 Confidence: 80 Actionability: 70	keep open	Replace hardcoded exit codes with os.EX_* constants. PR #387 merged for simple cases; 128+SIGINT constant, magic numbers 77/75, and exposed error codes for tests remain.
2026-09-01 04:16 AM UTC	qwen/qwen3.8-27b	Impact: 15 Quick Win: 13 Staleness: 72 Complexity: 15 Confidence: 80 Support Request: 0	keep open	Refactor request to replace hardcoded sysexits.h magic numbers with os.EX_* constants in application.py, errors.py, remotebuild.py, and to expose error exit codes for tests. PR #387 merged and fixed the simple cases; 128+SIGINT and a few magic numbers (77/75) remain.
2026-07-22 12:16 PM UTC	qwen/qwen3.6-35b-a3b	Staleness: 90 Complexity: 15 Confidence: 85 Support Request: 0	close stale	Refactor request to replace hardcoded exit codes with standard os.EX_* constants and expose error exit codes for testing. Partially addressed via PR #387, but stalled for over a year with no further maintainer action.
2026-07-08 11:56 PM UTC	qwen3.6-35b-a3b-mtp-q6	Staleness: 85 Complexity: 20 Confidence: 70 Support Request: 5	needs triage	Suggests replacing hardcoded exit codes with Python os module constants and exposing error codes for testing. PR 387 handles simple cases, but signal-based exit codes remain unresolved. Unlabelled and inactive for over a year.

Update history

No update history recorded yet.

Related work

Likely Fixed By: canonical/craft-application#387 (confidence 92%)
Merged as e8651e46 'refactor: use exit code constants when possible'; lengau created it to 'handle the simple cases' of this issue, leaving the 128+SIGINT and PartsError/ProviderError retcode items open.

Related issues

No related issues found above the similarity threshold.