search

conda-forge / staged-recipes

A place to submit conda recipes before they become fully fledged conda-forge feedstocks
https://conda-forge.org
BSD 3-Clause "New" or "Revised" License
698 stars 4.84k forks source link

Add a pixi project for local development? #26980

Open baszalmstra opened 1 month ago

baszalmstra commented 1 month ago

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 commented 1 month ago

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

xhochy commented 1 month ago

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 commented 1 month ago

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 commented 3 weeks ago

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.