✨ 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.
| 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.