`pixi build` proposal

gistfile1.txt

# `pixi build` proposal

This proposal describes a first version of the `pixi build` command

## The goal of this proposal
Get a plan ready for the development stage of the `pixi build` currently for conda only but the proposal shouldn't disallow a version of `pixi build --pypi` for building pypi packages.

## The motivating example
There are multiple scenarios where `pixi build` and it's mechanics are useful

- Building conda packages directly from a pixi project
- Depending on a pixi project as a dependency with the intermediate step of building the package for you.
- Making pixi a complete package management tool and not just the installer/runner.

## Design Considerations

There are a few things we want to keep in mind in the design:

1. **User-friendly** Pixi is a user focussed tool that goes beyond developers. The feature should have good error reporting and helpful documentation from the start. 
2. **Keep it simple** Not understanding the build logic and command shouldn't limit a users to use pixi for the other parts of it. Thus it should be "invisible" for non buildable environments.
3. **Opt-in** The feature should be opt-in, so it would required some form of specifying in the manifest file to allow for the building. Either through automatic injection or manual manipulation of the file. 
4. **Based of rattler-build** The feature should be an extention of the `rattler-build` tool into pixi. `pixi build` should not have features that are not present in `rattler-build build`.
5. **Reproduciblity** The packages built by pixi should be reproducible from the start. This allows for easier future integration of build caching for pixi dependencies. 
6. **Multi output package** The spec should be setup in such a way that 

## Things `pixi build` is not
- There will be no `source` defintion as the project itself is the source.

## Proposal
Allow pixi to generate a `recipe.yaml` recipe file that `rattler-build` can understand and build. `rattler-build` should be extended with the `deno_task_shell` runner so tasks can be run directly as build scripts. 


## Definition in manifest file

The same definition should be usable in `pyproject.toml` and `pixi.toml`, continuing with the `pixi.toml` for simplicity.

```toml
[project]
name = "project"
version = "1.2.3" # Becomes a requirement for building the package.
channels = ["conda-forge"]

# Keeping build to later extend with `[pypi-build]` if ever required.
[build]
number = 0
type = "noarch" # or not
# Allowing for pixi tasks from the [tasks] table.
build-scripts = ["build-task"]
test-scripts = ["test-package"]

[tasks]
build-task = "python -m pip install --no-deps --ignored-installed ."
test-package = "pytest -s"

[build-dependencies]
git = "2.45.1"

[host-dependencies]
python = ">=3.10"
pip = ">=24.0"

[dependencies]
python = ">=3.10"
```

### WHAT TO DO WITH THE IF THEN CLAUSES?

### HOW DO WE HANDLE MULTI OUTPUT PACKAGES, ENVIRONMENTS?

### HOW DO WE HANDLE THE JINJA TEMPLATES (cdt, compiler, pin_subpackage)

### HOW DO WE SUPPORT VARIANT CONFIG?

### HOW TO HANDLE BUILD SUBDIR