Add a pixi project for local development?

[baszalmstra]

General comment:

Im working on adding support for rattler-build to this repository. I was wondering if you would be against adding a pixi project inside the .github/workflows/scripts folder to make it easier to run the script inside there locally.

I can imagine there would be a concern that it would lock the dependencies instead of resolving them every time (which currently seems to be the case). But I could either just not commit the lock file or add a workflow to automatically update the lock file from time to time.

If yes, would you want to switch to pixi completely for the create-feedstock script in CI? We could then use the setup-pixi action.

If not, would it be appropriate to add a .gitignore to the scripts folder to exclude any pixi related files, so I can locally at least use it?

@conda-forge/staged-recipes

[baszalmstra]

Note that in #26981 I added a .gitignore for my local pixi project files.

[xhochy]

Personally, I'm happy to have a pixi project here. What would be your reasoning to put it into the .github/workflows/scripts folder?

[baszalmstra]

I wanted to put it close to the infrastructure code of the repository to not confuse users when they start with the repository. But Id be more than happy to move it to the root!

[bollwyvl]

As a recipe contributor, I would see substantial value in a non-obscured /pixi.toml project, but indeed a .gitignored pixi.lock, which would be burdensome for contributors to keep up-to-date with upstream.

If a pixi.lock were checked in, but still .gitignored, it might be reasonable to maintain in an automated way that didn't create a lot of PR noise.

Overall, this could reduce the complexity of the happy path for someone with a miniforge but unfamiliar with pixi down to:

mamba install pixi
pixi r grayskull some-new-package # optional, in its own env
pixi r lint [some-new-package]
pixi r build [some-new-package]
# or
pixi r docker [some-new-package]

Where omitting the package name would Do The Right Thing, especially in a multi-recipe PR.