Add basic Pixi config in pyproject.toml and developer instructions

[backmari]

Description

Adds a basic Pixi configuration to the pyproject.toml and instructions for setting up your developer environment using Pixi. The reason for adding Pixi as an option is that many institutions are moving from conda to Pixi due to conda licensing changes.

This is related to #3690, but does not resolve the issue. There is more work to do to e.g. move the CI to use Pixi, but that may require some discussion.

TODO (in a separate PR?): Figure out how to build the docs using a Pixi task and have the docs changes reflected in the GUI.

How Has This Been Tested?

I tested that I can create the developer environment, run the GUI, and run the unit tests:

pixi shell
sasview
pixi run test

I have only tested on Linux.

Review Checklist:

[if using the editor, use [x] in place of [ ] to check a box]

Documentation (check at least one)

• There is nothing that needs documenting
• Documentation changes are in this PR
• There is an issue open for the documentation (link?)

Installers

• There is a chance this will affect the installers, if so
  • Windows installer (GH artifact) has been tested (installed and worked)
  • MacOSX installer (GH artifact) has been tested (installed and worked)
  • Wheels installer (GH artifact) has been tested (installed and worked)

Licensing (untick if necessary)

• The introduced changes comply with SasView license (BSD 3-Clause)

[llimeht]

There are a few conceptual things that need to be figured out collectively - particularly around pinning of dependencies. cf. https://github.com/orgs/SasView/discussions/3831

[krzywon]

As a reminder from our meeting, the developer environment setup is available at https://github.com/SasView/sasview/wiki/DevNotes_DevEnvironmentInstall

[krzywon]

Nitpick: This is in both the venv and Pixi instructions. This shouldn't hold up this PR, but might make sense to add a section called Obtaining the source code. This section could also have instructions on cloning the bumps and periodictable repos.

[backmari]

I made a change to extract this part into a section "Prerequisites". Please see if you think it makes sense.

[krzywon]

Code and documentation look good, but I'll leave testing the setup procedure to someone more familiar with pixi.

[butlerpd]

@llimeht your hold on this dates back to Jan I was wondering but everything seems to have been resolved? There is an approving review as well so wondering if you had further comments?

[llimeht]

Should pixi.lock instead be in .gitignore since it is not being added?

[llimeht]

missing word "environment" or some other rewording? (venv is both a tool and an environment type, pixi is a tool that manages environments)

[llimeht]

The edit to INSTALLmd says that it will grab the packages from pypi but this says conda-forge?

[llimeht]

but everything seems to have been resolved?

There is three very fundamental questions that I've not seen any resolution to (but might have been discussed at a developer meeting?):

• why make installing it look harder than it is by providing multiple different sets of instructions; if pixi is useful to document, perhaps it should be in a separate file. We have already received bug reports from folks who have looked at INSTALL.md, tried to simplify it, and then reported that it didn't work.
• there are quite literally dozens of projects like pixi appearing at the moment; why pixi? are we going to document all of them as each person picks their favourite? (noting that we don't include how to build linux packages for any distros or flatpak within the installation instructions either)
• what happens when (not if) installation via pip and pixi generate different outcomes (and bugs)? This is both a pragmatic question (the more different routes in we have, the thinner the testing is, and more problems we will be surprised by later.) and a policy question (if we have to choose, how do we then do so? there are other useful things that I could have done in CI that I didn't to maintain compatibility with pip, since it has a special place as the benchmark tool).

I also see that there's no test that the package is installable via pixi. Should there be? CI currently tests building the wheel and installing it via pip.