Repository navigation
docs: clarify how pixi resolves conda vs PyPI dependencies - #819
InessaPawson wants to merge 1 commit into
Conversation
✅ Deploy Preview for python-package-guide ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
@ruben-arts We'd appreciate your feedback on this PR. 🙏 |
4294a4d to
7f392e3
Compare
|
@all-contributors please add @ruben-arts for review, docs |
|
I've put up a pull request to add @ruben-arts! 🎉 |
| pixi add numpy | ||
|
|
||
| # Install your package in dev mode | ||
| # Install your package in dev mode from PyPI |
There was a problem hiding this comment.
Hey there, @InessaPawson, I have a question. Installing in dev mode frm PyPI doesn't fit into my mental model of editable mode because I think editable mode is when you work on the package locally so it's a local link to the package's flat files, and you can edit those files and restart the "kernel" or python session to see the new changes live. So it's not from PyPI
| # Install your package in dev mode from PyPI | |
| # Install your package in development (or editable) mode |
|
|
||
| # Add Python packages | ||
| pixi add numpy pandas | ||
| # Add packages from conda-forge (the default) |
There was a problem hiding this comment.
| # Add packages from conda-forge (the default) | |
| # Add packages from conda-forge (Pixi's default) |
|
|
||
| # Add conda packages (like GDAL) | ||
| pixi add gdal | ||
| # Add packages from PyPI (only if a package isn't on conda-forge) |
There was a problem hiding this comment.
| # Add packages from PyPI (only if a package isn't on conda-forge) | |
| # Add packages from PyPI (only do this if a package isn't on conda-forge) |
There was a problem hiding this comment.
I am not sure, but i wonder if this is a best practice - so only install from pypi if it's not on conda-forge, and this would be because of channel mixing being "dangerous" to do in environments? ignore if i am wrong as i am not an active pixi user!
| pixi shell | ||
| ``` | ||
|
|
||
| The commands above produce a manifest like this: |
There was a problem hiding this comment.
| The commands above produce a manifest like this: | |
| The commands above produce output toml file (also known as a manifest) that describes your environment setup like this: |
| scipy = ">=1.16.3, <2" | ||
| ``` | ||
|
|
||
| Here, Pixi installs `numpy` and `gdal` from conda-forge and only `scipy` from PyPI. You can confirm where each package came from with `pixi list`. |
There was a problem hiding this comment.
| Here, Pixi installs `numpy` and `gdal` from conda-forge and only `scipy` from PyPI. You can confirm where each package came from with `pixi list`. | |
| Here, Pixi installs `numpy` and `gdal` from conda-forge and `scipy` from PyPI. You can confirm where each package came from with `pixi list`. |
|
|
||
| Here, Pixi installs `numpy` and `gdal` from conda-forge and only `scipy` from PyPI. You can confirm where each package came from with `pixi list`. | ||
|
|
||
| This is the same outcome as creating a conda environment, installing `numpy` and `gdal` with conda, and then running `pip install scipy` inside it. The difference is that the conda-vs-PyPI split is declared explicitly in the manifest and captured in the lock file, so there is no ambiguity about how a given dependency will be resolved at install time. |
There was a problem hiding this comment.
| This is the same outcome as creating a conda environment, installing `numpy` and `gdal` with conda, and then running `pip install scipy` inside it. The difference is that the conda-vs-PyPI split is declared explicitly in the manifest and captured in the lock file, so there is no ambiguity about how a given dependency will be resolved at install time. | |
| The above process, which created a Python environment using Pixi, produces the same outcome environment as you might do creating a conda environment using `conda create` and then installing `numpy` and `gdal` with conda, and then running `pip install scipy` inside it. The difference is that the conda-vs-PyPI split is declared explicitly in the manifest and captured in the lock file, so there is no ambiguity about how a given dependency will be resolved at install time. |
There was a problem hiding this comment.
This statement is actually confusing too. You can add a pip: section to a conda environment. yml file. and that is explicit. Can you clarify what this actually does that is different from using an environment.yml file that has a pip section?
i think maybe leaning into the speed gains might be a better summary saying - this is similar to creating a conda environment with a pip section - so it's declarative but pixi adds
x, y, z value to. the process
Emphasize the similarities, but also how they differ and how Pixi gives you more power. @ruben-arts I'd love your input here because I am not a Pixi user, but this statement doesn't clearly articulate the value I think Pixi provides to a user!
lwasser
left a comment
lwasser
left a comment
There was a problem hiding this comment.
I'd actually love some changes on this one to clarify the power of pixi vs just using conda. great additions here !!
This branch has not been deployed
3 participants
Updates the pixi section to make clear that
pixi addinstalls from conda channels by default andpixi add --pypiinstalls from PyPI, with a matching manifest example.Closes #589.