.. I'm surprised the tests are running given I labelled this [ci doc]

It is my understanding that if you have metadata about the build you are (or will soon be able) to point to a repo as a conda dependency and pixi-build will build the conda-package on the fly (the same way it does with pypi-deps). Given that we are going to want pixi.toml in the lop level eventually.

That said, I agree we do not want to check in the pixi.lock file.

I mean add a section like

[pypi-dependencies]
matplotlib = { path = "..", editable = true }

Ah I see. No that didn't work as I don't think it's compatible with build isolation.

OK< my comment above was incorrect. The new pixi.toml has removed the font copying things, and uses

[pypi-dependencies]
matplotlib = { path = ".", editable = true }

which indeed seems to be fine.

Still not sure if we should run with features or just a separate install steps?

Note: Mypy errors are based on a new mypy release yesterday, which improves type narrowing. https://mypy.readthedocs.io/en/stable/changelog.html

Unrelated to here, but needs investigation.

Built docs are here: https://output.circle-artifacts.com/output/job/2a1cb0cd-b9e6-487d-8213-ccadbf52b0b5/artifacts/0/doc/build/html/devel/development_setup.html

Not sure about the Note... Tip... Note... I think I'll move the pyproject.toml note up to be a warning as we really don't want people to edit that unless absolutely necessary.

EDIT: combined the two tips, and made the note about pyproject.toml a warning.

https://output.circle-artifacts.com/output/job/7fa2bf9b-db3d-464c-aa8e-8e8c8829cdb9/artifacts/0/doc/build/html/devel/development_setup.html

Do we need the warning at all? / Do we need the warning here?

This is about dev environment setup. Somebody setting up is not likely to mess with existing configuration. We also don’t warn on the other environment setups.

This is about dev environment setup. Somebody setting up is not likely to mess with existing configuration. We also don’t warn on the other environment setups.

I guess I'm not sure, partially out of ignorance for how others work.

The central tension here is between what a casual developer wants, which is a pixi.toml that they may want to edit, versus what we want for CI which is to check and create the canonical pixi.lock that we want to preserve for posterity.

If someone can't get pixi install to work out of the box, they may be tempted to change pyproject.toml because that is where pixi is getting the manifest. We'd rather they copy tools/pixi.toml locally, and modify that, and then do pixi install.

However, I'm very open to the idea that the way I've suggested we resolve this tension here is not the best one. You could imagine the CI-verified pixi.lock goes somewhere more discrete than the top level, and the burden to update it belongs to experienced developers who change the project requirements. That would be a bit of reorganization here, but may be cleaner.

My primary question would be: Isn’t the config we provide here good enough for the average developer? There could be expert use cases, but I’d trust that experts know enough to not mess up.

I would only discuss a custom pixi.toml if that is a typical use case: And then its usage should be explicitly explained somewhere around here.

Also, we have the PR review, so that we will catch improper updates.

Overall, I’d leave this out and only add the warning, if improper updates become reasonably common.

Note: I did a pixi setup yesterday on a fresh machine, and it went quite smooth with the preconfigured settings.

Running tests is possible.

Doc build is a bit fiddly because Sphinx crashes with awkward messages if the “external” dependencies Ghostscript and Latex are not available. That’s not a direct issue of pixi, but we could consider including the Ghostscript conda package (in a follow up PR).

My primary question would be: Isn’t the config we provide here good enough for the average developer?

I think so, and it's encouraging that it works on at least three machines (mine, yours, and CI)

The goal with the warning was just to alert folks not to edit pyproject.toml. However, happy to remove that section and add it back if it becomes problematic.

@tacaswell what do you think is missing to get this in as a minimal starting point? I'd like to experiment with this in regular usage, and for that it'd be nice to have the config on main.

Anyone else have comments on this? @tacaswell or @QuLogic ? I needed to install something and realized I can't actually use this until its merged ;-)

• I remain deeply skeptical of mixing pixi config in to pyproject.toml stuff. I think it crosses two packaging ecosystems in bad ways (for example, the current lock file has 986 things installed from pypi which is very much less than ideal). I'll push a commit to fix that. One selling point of pixi is it is fast, but the other major selling point is getting away from the wheel ecosystem all together.
• I still prefer to let pixi do the editable install, but I have not thought through possible issues in CI. The instruction of pixi run test and pixi run docs being so simple is something it feels hard to give up. I think we can give up the CI check that the lock is consistent if saves us install steps (particularly because mpl-sphinx-theme depends on us so we always install a version and then install over it).
• I think nice things are coming with https://pixi.prefix.dev/dev/build/backends/pixi-build-python/#ignore-pypi-mapping which will hopefully let us drop the duplication and make it so that you can add the main branch of mpl as a conda dep to another pixi config.

The lock check failing may be a v6 vs v7 thing on the lock file (which is coupled to pixi 0.68).

I'm more than happy for someone else to take this over or redo it. I maintain a willful ignorance of the packaging ecosystem. Conversely, it'd be nice to have something that works.

the current lock file has 986 things installed from pypi

That’s strange. I thought conda-forge is given precedence, and the environment.yml in our project root shows that most of the dev environment can be built on conda.

Anyway, we might want to use a pixi.toml for configuration and better separation. Inspiration could be taken from scipy, who have a fairly comprehensive setup.