Proposal: Version override argument for pixi publish
#6663
thomas-lemma
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
A common pattern for CI pipelines is to publish a development package with a PEP440-compliant version like
major.minor.patch.devN, wheremajor.minor.patchcomes from the source manifest and the indexNis typically supplied in one of two ways:N = $GITHUB_RUN_NUMBER(or equivalent).Current state as I understand it — please correct me if I've overlooked an existing option or misunderstand the design around pixi build. At present, the conda package version is defined statically by
[project].version(pyproject.toml) or[package].version(pixi.toml). Changing it at CI time requires rewriting a tracked manifest file before runningpixi publish— there is no CLI flag, env-var override, or[package.build.config]mechanism that overrides it.Question. Would a CLI-level version override on
pixi publish— e.g.pixi publish --override-version 1.2.3.dev29— be something the pixi team would consider useful and aligned with the vision for the tooling?Some advantages of this option might be:
--build-numberand--build-string-prefixfor controlling the other components of the conda package identifier.Happy to discuss this further if it seems worth exploring. Thanks a lot!
All reactions