Checks
Reproducible example
We encountered this issue while working on rerun-io/rerun#5966 (can be reproduced with commit 44412db2519cf2a37b0bd9d951cc4d8630eac037).
rm -rf .pixi
pixi run -e examples clock
# error indicating that rerun-sdk is pulled from pypi as expected
pixi run -e examples py-build # calls maturin develop, which calls pip — should fix the error
pixi run -e examples clock
-> leads to the same initial error, as if py-build had no effect.
Issue description
It actually turns out that py-build does install a build-from-source rerun-sdk correctly, but this is reverted by the last call to pixi, possibly due to #998?
Interestingly, activating a shell is a possibly work-around:
rm -rf .pixi
pixi run -e examples clock
# error indicating that rerun-sdk is pulled from pypi as expected
pixi shell -e examples
pixi run -e examples py-build
clock # -> works as expected
Another case where it appears to work as expected is in CI, with an environment set for the setup-pixi action: https://github.com/rerun-io/rerun/blob/36f00a5b0bd3edf06bc0f4ec65ce58f86a32e458/.github/workflows/reusable_build_examples.yml#L66-L86
Expected behavior
Ideally, pixi would make it easy and robust to manually "override" packages in the environments, including via pip specifically for when there is no other way (e.g maturin). This would cover at least two workflow:
- dev environment (run ${STUFF} against a build-from-source rerun)
- CI (run/test ${STUFF} against a CI-built wheel)
Workaround
For our particular case, @jleibs just had a workaround idea that appears to work:
- we created a "empty"
rerun-sdk local package somewhere (that would install a differently named empty python file)
- we added an explicitly dependency on it in
pixi.toml for the examples environment
That way, examples defaults to failing (no module named 'rerun'), and somehow a subsequent pixi run -e examples py-build doesn't end up being overridden.
pyproject.toml:
[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"
[project]
name = "rerun-sdk"
version = "0.10.0"
[tool.hatch.build.targets.wheel]
packages = ["empty_rerun_sdk.py"]
Checks
I have checked that this issue has not already been reported.
I have confirmed this bug exists on the latest version of pixi, using
pixi --version.Reproducible example
We encountered this issue while working on rerun-io/rerun#5966 (can be reproduced with commit 44412db2519cf2a37b0bd9d951cc4d8630eac037).
-> leads to the same initial error, as if
py-buildhad no effect.Issue description
It actually turns out that
py-builddoes install a build-from-source rerun-sdk correctly, but this is reverted by the last call to pixi, possibly due to #998?Interestingly, activating a shell is a possibly work-around:
Another case where it appears to work as expected is in CI, with an environment set for the
setup-pixiaction: https://github.com/rerun-io/rerun/blob/36f00a5b0bd3edf06bc0f4ec65ce58f86a32e458/.github/workflows/reusable_build_examples.yml#L66-L86Expected behavior
Ideally,
pixiwould make it easy and robust to manually "override" packages in the environments, including via pip specifically for when there is no other way (e.g maturin). This would cover at least two workflow:Workaround
For our particular case, @jleibs just had a workaround idea that appears to work:
rerun-sdklocal package somewhere (that would install a differently named empty python file)pixi.tomlfor theexamplesenvironmentThat way, examples defaults to failing (
no module named 'rerun'), and somehow a subsequentpixi run -e examples py-builddoesn't end up being overridden.pyproject.toml: