Skip to content

feat: Add support for SOURCE packages#244

Merged
Pavel Zwerschke (pavelzw) merged 27 commits into
Quantco:mainfrom
toprinse:add_source_pkg_handling
Jul 3, 2026
Merged

feat: Add support for SOURCE packages#244
Pavel Zwerschke (pavelzw) merged 27 commits into
Quantco:mainfrom
toprinse:add_source_pkg_handling

Conversation

@toprinse

@toprinse Thibaut OPRINSEN (toprinse) commented Nov 24, 2025

Copy link
Copy Markdown
Contributor

Motivation

This PR adds support for building packages from source, a feature that is currently missing. See issue #80 for background and motivation.

When a local package is found in the pixi.lock of the main package, start a pixi-build command to build the local dependencies and add them as injected packages in the environment.tar

Changes

  • Introduces a pixi-build command to automatically build local packages from the main pixi.lock
  • Adding integration test to demonstrate the the added code is working as expected.

Closes #80

@toprinse Thibaut OPRINSEN (toprinse) changed the title feat : Add support for SOURCE packages feat: Add support for SOURCE packages Nov 24, 2025
@github-actions github-actions Bot added the enhancement New feature or request label Nov 24, 2025
fix: remove unused fixture

fix: fix typo

fix: fix typo

fix: fix typo

fix: fix test on arm-64, osx and win builds

fix: fix test on arm-64, osx and win builds

fix: add valid checksum for other architectures

fix: fix test using correct checksum

fix: fix typo error

fix: fix typo
Comment thread src/pack.rs Outdated
Comment thread src/pack.rs Outdated
Comment thread src/pack.rs Outdated

@pavelzw Pavel Zwerschke (pavelzw) left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks very solid already, thanks!
I have a couple of comments

Comment thread examples/local-build/local-pkg/pixi.toml Outdated
Comment thread src/pack.rs
Comment thread src/pack.rs Outdated
Comment thread src/pack.rs Outdated
Comment thread src/pack.rs Outdated
Comment thread src/pack.rs Outdated
Comment thread src/pack.rs Outdated
Comment thread src/pack.rs Outdated
Comment thread tests/integration_test.rs Outdated
Comment thread tests/integration_test.rs Outdated
Comment thread src/pack.rs Outdated
fix: fix typo for ci precommit

fix: fix typo for ci precommit

fix: fix typo for ci precommit
@toprinse

Copy link
Copy Markdown
Contributor Author

Thanks Pavel Zwerschke (@pavelzw) ! So I made the requested changes, could you review the new version and tell me if there are some changes that are not relevant or things I could have done better ?

Comment thread examples/local-build/pixi.toml
Comment thread src/pack.rs Outdated
.arg(output_dir)
.arg("--build-platform")
.arg(platform)
.current_dir(manifest_dir);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

with things like PIXI_PROJECT_ROOT (set by pixi shell) i think it's safer to explicitly use pixi build --path

@pavelzw Pavel Zwerschke (pavelzw) Dec 1, 2025

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, another thing i noticed:

❯ cd examples/local-build/
❯ cargo run --bin pixi-pack --
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.99s
     Running `/Users/pavel/projects/pixi-pack/target/debug/pixi-pack`
⠁ Building local-build-main-pkg-0.1.0-hbf21a9e_0.conda                                                                                                                          
❌ Build failed with exit code: Some(1)
Command: pixi build --output-dir /var/folders/rz/q1r4tv0n6ll38q18fbk419mc0000gn/T/.tmpZQnitN --build-platform osx-arm64 (in /Users/pavel/projects/pixi-pack/examples)
📤 stderr:
Error:   × the source directory '/Users/pavel/projects/pixi-pack/examples', does not contain a supported manifest
  help: Ensure that the source directory contains a valid pixi.toml, pyproject.toml, recipe.yaml, package.xml or mojoproject.toml file.


Error: Failed to build package in /Users/pavel/projects/pixi-pack/examples

❯ cargo run --bin pixi-pack -- pixi.toml
   Compiling pixi-pack v0.7.5 (/Users/pavel/projects/pixi-pack)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 8.78s
     Running `/Users/pavel/projects/pixi-pack/target/debug/pixi-pack pixi.toml`
  ✅ Built local-build-main-pkg-0.1.0-hbf21a9e_0.conda
  ✅ Built local-build-local-pkg-0.1.0-hbf21a9e_0.conda
  ✅ Built local-build-local-pkg-2-0.1.0-hbf21a9e_0.conda
⏳ Downloading 14 packages...
📦 Created pack at /Users/pavel/projects/pixi-pack/examples/local-build/environment.tar with size 7.70 MiB.

something is still wrong with the manifest path...

@toprinse Thibaut OPRINSEN (toprinse) Dec 2, 2025

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated the base_dir logic to correctly handle manifest paths when building source packages. Previously, when options.manifest_path was a directory (not a file), the code incorrectly used its parent directory as the base, causing build failures with paths like /examples/./pixi.toml. Now it properly uses the manifest directory itself as the base when it's a directory. Also added canonicalize() to resolve relative paths (like ./) and ensure the manifest file exists before attempting to build.

oprinsen@lappc-p1138 local-build ⌥  (add_source_pkg_handling) cargo run --bin pixi-pack --
   Compiling pixi-pack v0.7.5 (/home/oprinsen/pixi-pack)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.62s
     Running `/home/oprinsen/pixi-pack/target/debug/pixi-pack`
DEBUG: options.manifest_path = /home/oprinsen/pixi-pack/examples/local-build
DEBUG: source_data.location = Path(Unix(Utf8PathBuf { _encoding: "unix", inner: "." }))
DEBUG: base_dir = /home/oprinsen/pixi-pack/examples/local-build
  ✅ Built local-build-main-pkg-0.1.0-hbf21a9e_0.conda                                                                                                                                        DEBUG: options.manifest_path = /home/oprinsen/pixi-pack/examples/local-build
DEBUG: source_data.location = Path(Unix(Utf8PathBuf { _encoding: "unix", inner: "local-pkg" }))
DEBUG: base_dir = /home/oprinsen/pixi-pack/examples/local-build
  ✅ Built local-build-local-pkg-0.1.0-hbf21a9e_0.conda                                                                                                                                       DEBUG: options.manifest_path = /home/oprinsen/pixi-pack/examples/local-build
DEBUG: source_data.location = Path(Unix(Utf8PathBuf { _encoding: "unix", inner: "local-pkg2" }))
DEBUG: base_dir = /home/oprinsen/pixi-pack/examples/local-build
  ✅ Built local-build-local-pkg-2-0.1.0-hbf21a9e_0.conda                                                                                                                                     ⏳ Downloading 21 packages...
📦 Created pack at /home/oprinsen/pixi-pack/examples/local-build/environment.tar with size 15.28 MiB.
oprinsen@lappc-p1138 local-build ⌥  (add_source_pkg_handling) 

Comment thread src/pack.rs
@pavelzw

Pavel Zwerschke (pavelzw) commented Dec 1, 2025

Copy link
Copy Markdown
Member

pushed some adjustments to your branch; after the manifest dir fixes, this is good to merge 👍🏻

fix: fix typo
@toprinse

Copy link
Copy Markdown
Contributor Author

Hello Pavel Zwerschke (@pavelzw), I saw that the tests have failed after merging main into my branch. Is the issue linked to the hash or the build_version of the generated packages which has changed after merging the two branches ? I don't really know how to make the test reliable, as we hardcoded the hash and version in the tests, and I don't really know how to do it in another way. If I can do anything, just let me know !

@pavelzw

Copy link
Copy Markdown
Member

yeah this looks really weird to me. sounds like a bug in pixi tbh.
i will create a minimal reproducer and see what the pixi people think of this one

@toprinse

Copy link
Copy Markdown
Contributor Author

Hello Pavel Zwerschke (@pavelzw).

So I looked into the issue of the regenerated hashes and it seems that recently the cmake build backend used in the tests has been updated and the hash generation might have been impacted. I'm not sure about how it impacted the tests and it's still unclear to me but for now I added the new generated hashes using the cmake build backend 0.3.5 (maybe it could be intersting to pin the build backend version in the test to avoid new strange behaviors).

Another idea could be to use match patterns instead of the exact version of the package containing the hashes. Instead of looking for conda-meta/local-build-main-pkg-0.1.0-hb0f4dca_0.json we could also use something like starts_with("local-build-main-pkg-0.1.0-") inside the conda-meta directory.

I also updated the pixi version to use 0.61.0 so the API of pixi build command has changed a bit in pack.rs

@pavelzw

Pavel Zwerschke (pavelzw) commented Dec 18, 2025

Copy link
Copy Markdown
Member

Sorry for not coming back to you, lost track of this pr. One thing I'm wondering is why the build string from the pixi.lock didn't match the build string of the built package 🤔 theoretically the lockfile should always match the package exactly and thus represent the correct build string already? Maybe I'm missing something, will investigate later

In general, i think pinning the build backend makes sense in this case 👍🏻

I think it would be nice if we even persisted the build backends and host+build environments used in pixi.lock (optionally): prefix-dev/pixi#5161

@toprinse

Copy link
Copy Markdown
Contributor Author

Sorry for not coming back to you, lost track of this pr. One thing I'm wondering is why the build string from the pixi.lock didn't match the build string of the built package 🤔 theoretically the lockfile should always match the package exactly and thus represent the correct build string already? Maybe I'm missing something, will investigate later

In general, i think pinning the build backend makes sense in this case 👍🏻

I think it would be nice if we even persisted the build backends and host+build environments used in pixi.lock (optionally): prefix-dev/pixi#5161

No problem, I was also really busy!

I can pin the build backend version in the tests to the latest version (0.3.5).

Regarding the build string mismatch issue, I'm not sure what approach you'd prefer: should we wait for pixi to provide a clear fix for this issue, or would you prefer to merge the PR as-is and address the build string inconsistency once pixi implements the changes mentioned in the issue you linked?

@vincent-pollet

Copy link
Copy Markdown

Hello! May I kindly ask what is the status about this PR? Anything that we could help with?

@vincent-pollet

Copy link
Copy Markdown

Pavel Zwerschke (@pavelzw) Sorry to ping you, is there anything we can do to help this get merged?

@pavelzw

Copy link
Copy Markdown
Member

we now cleaned up and merged all other PRs and this one is next, sorry to keep you waiting for so long.

pixi lockfile v7 are coming soon-ish (prefix-dev/pixi#5607, conda/rattler#2026) and will lead to the version field not being fully required anymore.
we need to

  • merge main into this branch and resolve conflicts
  • see how the new lockfile format affects this PR.

@toprinse

Copy link
Copy Markdown
Contributor Author

Hello Pavel Zwerschke (@pavelzw) .
So I merged the main branch into this one, fixed the conflicts and update tests.
I made a few changes :

  • I removed the win64 test (see comments in integrations_tests.rs because they were failing because the generated path from pixi build is too long. There is currently no clean solutions to avoid reaching these windows limitations.
  • Then, I'm not sure why but the test_pixi_pack_source sometimes fail, even I don't add major changes. I then get :
---- test_pixi_pack_source stdout ----
⏳ Downloading 25 packages...

thread 'test_pixi_pack_source' (13156) panicked at tests/integration_test.rs:858:5:
Err(could not download package: error decoding response body)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Maybe you have a better idea about what's happening ?

@pavelzw

Copy link
Copy Markdown
Member

Then, I'm not sure why but the test_pixi_pack_source sometimes fail, even I don't add major changes

this looks like a networking issue and the package got dropped. maybe we need to add retries to the Client if we haven't done so already

@pavelzw

Copy link
Copy Markdown
Member

Lockfile v7 is now on main (of pixi). This means we should be able to test against it :)

@pavelzw

Copy link
Copy Markdown
Member

Added support for lockfile v7 in #306. hopefully this fixes our reproducibility issues

@toprinse

Copy link
Copy Markdown
Contributor Author

Hello Pavel Zwerschke (@pavelzw). Sorry for the late answer. It's nice to have lockfiles v7 available !
Is there still things I can do for this PR ?

@pavelzw

Copy link
Copy Markdown
Member

I think we would need to merge main and then check again whether the tests would now be working reliably

@toprinse

Thibaut OPRINSEN (toprinse) commented May 27, 2026

Copy link
Copy Markdown
Contributor Author

Hello Pavel Zwerschke (@pavelzw). So, I merged main into this branch and fixed the breaking changes introduced by the rattler_lock refactor (specifically, CondaSourceData.package_record was removed — replaced by record() returning an Option<&PackageRecord>). The tests appear to be passing now. Still I'm not sure they are working reliably. Seems that the merge did not affect packages names and hashes in the test.

Comment thread src/pack.rs
Comment on lines +139 to +141
if !status.success() {
anyhow::bail!("Failed to publish package in {}", manifest_dir.display());
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in a follow-up we could stream the logs like pixi install

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment thread src/pack.rs
Comment on lines +239 to +241
UrlOrPath::Url(u) => {
anyhow::bail!("Unexpected URL for local package source: {}", u)
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this could be useful as well in a follow-up to support things like this:

[workspace]
preview = ["pixi-build"]
channels = ["conda-forge"]
platforms = ["linux-64", "linux-aarch64", "win-64", "osx-64", "osx-arm64"]

[dependencies]
agent-skill-conda-forge = { git = "https://github.com/pavelzw/skill-forge", rev = "main", subdirectory = "recipes/conda-forge" }

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@delsner Daniel Elsner (delsner) left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your work! Sorry that it took us a while to get this through.

@pavelzw Pavel Zwerschke (pavelzw) merged commit 62cb4f6 into Quantco:main Jul 3, 2026
15 of 19 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add support for Source conda packages

4 participants