✨ Introduce pixi for project management#489
Conversation
Add pixi manifest file and git-related files which are automatically generated by `pixi`
|
Hi @munechika-koyo, I like pixi and now I'm in the middle of switching from uv to it, so forgive me if my questions/comments are out of the line. What do we gain by adding pixi.toml and not integrating pixi into pyproject.toml? Isn't the disadvantage of having pixi.toml the need to keep requirements in the two toml files synchronised? Since pipy is Cherab's main package source, wouldn't it be better to prefer pipy packages in the toml file for now? Having only pyproject.toml and preferring pipy source, we can still keep the rest of the pixi features while not forcing users to migrate to pixi/conda. At least for some time. |
|
@Mateasek Thanks for your thoughtful question!
I used to manage a Python project similarly. However, because of integrating them into one toml file, it has relatively long lines, resulting in less readability. So I switched to this style, considering each file's role like:
Currently, cherab's
The reason why I prefer using conda packages for Although I believe this kind of thing should be okay for CI, we need to verify if the pypi package works well during deployment to pypi. I think users, even those who want to install |
|
Thank you for the explanation. |
Mateasek
left a comment
There was a problem hiding this comment.
Hi @munechika-koyo ,
I would be happy to merge this if @jacklovell and @skuba31 agree. I think Pixi is the right step forward. Last year I tested Poetry, UV and Pixi and for me Pixi is the winner so far. As I said earlier, it significantly improves the packaging experience to a bearable level
|
@Mateasek, Thank you for supporting this PR, and I apologize for not providing an example use case yet. |
Developer Tasks GuideThis document provides an overview of available development tasks configured in Basic Tasks (Default Environment without
|
|
Simply amazing @munechika-koyo , thanks! |
jacklovell
left a comment
There was a problem hiding this comment.
This looks good. Can you add the instructions from the PR discussion into a markdown file in the dev directory, so they're easy to find for developers without having to come back to this PR?
|
|
||
| # pixi environments | ||
| .pixi/* | ||
| !.pixi/config.toml |
There was a problem hiding this comment.
There's no .pixi/config.toml file in this PR. Does it really need to be un-ignored?
There was a problem hiding this comment.
These lines were automatically added by pixi when the pixi init command was run.
So it should probably be kept.
| setuptools = "*" | ||
| cython = ">=3.1" | ||
| numpy = "*" | ||
| raysect = "0.9.*" |
There was a problem hiding this comment.
Is there any way to auto-populate these from pyproject.toml? Otherwise we have 2 places to have to maintain dependency versions.
There was a problem hiding this comment.
There are two dependency sections:
- dependencies defined in pyproject.toml (or the
[pypi-dependencies]table in pixi.toml), where packages are downloaded from the PyPI index. - dependencies defined in
[dependencies]in pixi.toml, where packages are downloaded by conda.
Pixi prioritizes the conda packages, and only missing packages defined in pyproject.toml are downloaded through PyPI.
I prefer to use conda packages as much as possible to take advantage of conda-optimized packages, so I accounted for this maintenance cost.
There was a problem hiding this comment.
Additionally, in the [package.***-dependencies], we must specify conda packages because they are required to build the cherab conda package (not for workspace packages).
| scipy = "*" | ||
| matplotlib-base = "*" | ||
| pyopencl = "*" | ||
| pocl = "*" |
| compilers = ["c"] | ||
|
|
||
| [workspace.build-variants] | ||
| python = ["3.9", "3.10.*", "3.11.*", "3.12.*", "3.13.*"] |
| { arg = "target", default = "html" }, | ||
| ], description = "📝 Build the docs" } | ||
|
|
||
| # === Linting feature === |
There was a problem hiding this comment.
A pylint linter would be useful too as it's very thorough. It's also however very slow, so perhaps worth separating it out from the others so pixi run lint is fast and pixi run pylint is thorough but slow.
Adding suitable configurations for each of the linters is for another pull request, after some TMC discussion I think.
Added support for removing HTML build artifacts.
Renaming python-featured environments to avoid specific Python versions
Updated channels to use 'conda-forge' instead of the prefix's URL. Removed sphinx-tabs from pypi-dependencies.
Summary
I am introducing the package management tool,
pixi, to manage:package dependencies
development tools (linter, formatter, etc.)
task runners (building docs, testing, linting/formatting, etc.)
within each isolated virtual environment.
Key changes:
Added
piximanifest file forprojectworkspace configuration.Included git-related files for
version controlpixi-related configure files.Updated
.gitignoreto accommodatepixienvironments and lock files.