conda-ship 0.1.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- conda_ship-0.1.0/CHANGELOG.md +107 -0
- conda_ship-0.1.0/Cargo.lock +4808 -0
- conda_ship-0.1.0/Cargo.toml +100 -0
- conda_ship-0.1.0/LICENSE +28 -0
- conda_ship-0.1.0/PKG-INFO +191 -0
- conda_ship-0.1.0/README.md +167 -0
- conda_ship-0.1.0/pixi.toml +73 -0
- conda_ship-0.1.0/pyproject.toml +66 -0
- conda_ship-0.1.0/python/conda_ship/__init__.py +14 -0
- conda_ship-0.1.0/python/conda_ship/cli.py +238 -0
- conda_ship-0.1.0/python/conda_ship/plugin.py +31 -0
- conda_ship-0.1.0/src/bin/cs/artifact.rs +1417 -0
- conda_ship-0.1.0/src/bin/cs/bundle.rs +212 -0
- conda_ship-0.1.0/src/bin/cs/diagnostic.rs +148 -0
- conda_ship-0.1.0/src/bin/cs/project.rs +437 -0
- conda_ship-0.1.0/src/bin/cs/tests.rs +737 -0
- conda_ship-0.1.0/src/bin/cs.rs +384 -0
- conda_ship-0.1.0/src/cli.rs +365 -0
- conda_ship-0.1.0/src/commands.rs +639 -0
- conda_ship-0.1.0/src/config.rs +277 -0
- conda_ship-0.1.0/src/exec.rs +385 -0
- conda_ship-0.1.0/src/install.rs +680 -0
- conda_ship-0.1.0/src/main.rs +187 -0
- conda_ship-0.1.0/src/policy.rs +295 -0
- conda_ship-0.1.0/src/runtime_data.rs +468 -0
- conda_ship-0.1.0/src/snapshots/cs_template__config__tests__condarc.snap +12 -0
- conda_ship-0.1.0/src/snapshots/cs_template__config__tests__embedded_config.snap +7 -0
- conda_ship-0.1.0/src/snapshots/cs_template__config__tests__frozen.snap +8 -0
- conda_ship-0.1.0/src/tls.rs +7 -0
- conda_ship-0.1.0/tests/builder_diagnostics.rs +40 -0
- conda_ship-0.1.0/tests/cli_integration.rs +457 -0
- conda_ship-0.1.0/tests/conda_prompt_stdout_pipe_regression.rs +113 -0
- conda_ship-0.1.0/tests/exclude_integration.rs +52 -0
- conda_ship-0.1.0/tests/snapshots/cli_integration__runtime_help.snap +52 -0
|
@@ -0,0 +1,107 @@
|
|
|
1
|
+
# Changelog
|
|
2
|
+
|
|
3
|
+
All notable user-facing changes to `conda-ship` are documented here.
|
|
4
|
+
|
|
5
|
+
## 0.1.0 - 2026-06-01
|
|
6
|
+
|
|
7
|
+
Initial release of `conda-ship`, a generic builder for producing ready-to-run
|
|
8
|
+
conda runtimes from solved conda environments.
|
|
9
|
+
|
|
10
|
+
### Added
|
|
11
|
+
|
|
12
|
+
- The `cs` builder CLI.
|
|
13
|
+
- `cs inspect` checks the selected manifest, lockfile, source environment,
|
|
14
|
+
exclusions, platforms, and package set without writing files.
|
|
15
|
+
- `cs build` stages runtime artifacts.
|
|
16
|
+
- `cs build --dry-run` validates planned artifact work before downloading,
|
|
17
|
+
stamping, or writing files.
|
|
18
|
+
- `cs run` builds a runtime and immediately runs it for local smoke tests.
|
|
19
|
+
- The generic `cs-template` runtime template used to produce downstream runtime
|
|
20
|
+
binaries.
|
|
21
|
+
- Platform PyPI wheels that install `cs`, `cs-template`, and the Python adapter
|
|
22
|
+
together.
|
|
23
|
+
- A Python adapter that exposes `conda ship` as a conda-style shortcut for
|
|
24
|
+
`cs`, including structured builder diagnostics so common failures can be
|
|
25
|
+
reported predictably through conda.
|
|
26
|
+
- Build input from committed source manifests and lockfiles:
|
|
27
|
+
- `conda.toml` with `conda.lock`
|
|
28
|
+
- `pyproject.toml` with `[tool.conda]` and `conda.lock`
|
|
29
|
+
- `pixi.toml` with `pixi.lock`
|
|
30
|
+
- `pyproject.toml` with `[tool.pixi]` and `pixi.lock`
|
|
31
|
+
- `[tool.conda-ship]` build policy for generated runtimes, including the
|
|
32
|
+
runtime name, runtime version, delegate executable, source environment,
|
|
33
|
+
artifact layout, package exclusions, install scheme, install name, install
|
|
34
|
+
method, and documentation URL.
|
|
35
|
+
- Three artifact layouts:
|
|
36
|
+
- `online`, for small runtime artifacts that download packages during
|
|
37
|
+
bootstrap
|
|
38
|
+
- `external`, for a runtime plus a separate compressed package bundle
|
|
39
|
+
- `embedded`, for a larger single runtime that carries the compressed package
|
|
40
|
+
bundle inside the binary
|
|
41
|
+
- Generated runtime commands for `bootstrap`, `status`, `shell`, and
|
|
42
|
+
`uninstall`, plus pass-through support to the configured delegate executable.
|
|
43
|
+
- Generated runtime version output, so downstream binaries such as `cx` can
|
|
44
|
+
report their own distribution version instead of the generic conda-ship
|
|
45
|
+
builder version.
|
|
46
|
+
- Runtime install ownership metadata so generated runtimes can protect managed
|
|
47
|
+
prefixes from accidental use or removal by the wrong runtime.
|
|
48
|
+
- Install schemes for `~/.conda/INSTALL_NAME` and platform user data
|
|
49
|
+
directories, plus a runtime `--path` override for local testing and advanced
|
|
50
|
+
install paths.
|
|
51
|
+
- Staged runtime metadata files:
|
|
52
|
+
- `.runtime.lock`
|
|
53
|
+
- `.packages.txt`
|
|
54
|
+
- `.info.json`
|
|
55
|
+
- `.sha256`
|
|
56
|
+
- optional `.bundle.tar.zst` for `external` builds
|
|
57
|
+
- Package exclusion after source-lock resolution, so downstream distributions
|
|
58
|
+
can prune packages from a solved environment before building a runtime.
|
|
59
|
+
- Validation that the selected runtime environment contains the packages
|
|
60
|
+
required by generated runtimes: `conda`, `conda-rattler-solver`, and
|
|
61
|
+
`conda-spawn`.
|
|
62
|
+
- A composite GitHub Action for downstream release jobs. The action uses
|
|
63
|
+
committed manifest and lockfile input, verifies downloaded conda-ship release
|
|
64
|
+
assets, runs `cs build --dry-run`, and exposes `dist-path` for publishing the
|
|
65
|
+
complete generated artifact directory. Release jobs can override runtime
|
|
66
|
+
metadata such as runtime name, runtime version, delegate, layout, install
|
|
67
|
+
scheme, install name, install method, and documentation URL from workflow
|
|
68
|
+
inputs or matrices.
|
|
69
|
+
- Tagged release assets for `cs`, `cs-template`, and `SHA256SUMS`.
|
|
70
|
+
|
|
71
|
+
### Security And Provenance
|
|
72
|
+
|
|
73
|
+
- Bundle builds require SHA256 package metadata.
|
|
74
|
+
- Downloaded, cached, external, embedded, and offline package archives are
|
|
75
|
+
verified before they are staged or installed.
|
|
76
|
+
- Runtime templates refuse to run directly; `cs build` must stamp a template
|
|
77
|
+
before it becomes a downstream runtime.
|
|
78
|
+
- Runtime names, runtime versions, delegates, install names, install methods,
|
|
79
|
+
target labels, and documentation URLs are validated before they are stamped
|
|
80
|
+
into runtime binaries or artifact names.
|
|
81
|
+
- The GitHub Action verifies artifact attestations for downloaded `cs`,
|
|
82
|
+
`cs-template`, and `SHA256SUMS` assets before running them.
|
|
83
|
+
- The `conda ship` adapter only runs the `cs` executable installed in the same
|
|
84
|
+
Python environment, unless `CONDA_SHIP_EXECUTABLE` explicitly selects another
|
|
85
|
+
executable.
|
|
86
|
+
- Tagged GitHub releases publish immutable asset sets. If a release is wrong,
|
|
87
|
+
publish a new version instead of replacing files under an existing tag.
|
|
88
|
+
- GitHub workflows and the composite action use pinned actions, minimal
|
|
89
|
+
permissions, explicit artifact verification, and no shell `eval` for user
|
|
90
|
+
input.
|
|
91
|
+
- Release workflows use unprefixed version tags such as `0.1.0`.
|
|
92
|
+
- Release checks include Rust advisory, license, dependency-ban, and source
|
|
93
|
+
policy checks.
|
|
94
|
+
|
|
95
|
+
### Notes
|
|
96
|
+
|
|
97
|
+
- This is an alpha 0.1.0 release. The project is ready for early downstream
|
|
98
|
+
distribution work, but configuration details and artifact metadata may still
|
|
99
|
+
evolve before 1.0.
|
|
100
|
+
- `conda-ship` is not itself a conda distribution. Downstream projects choose
|
|
101
|
+
package sets, channels, runtime names, delegates, install methods, release
|
|
102
|
+
channels, signing policy, and user documentation.
|
|
103
|
+
- The GitHub Action should be used from a release tag. Branch refs do not have
|
|
104
|
+
matching `cs` and `cs-template` release assets. Use tags such as `0.1.0`,
|
|
105
|
+
without a leading `v`.
|
|
106
|
+
- Downstream release workflows should sign or attest the full `dist-path`
|
|
107
|
+
output after `cs build`.
|