feat(install): allow conda package subset selection (e.g. `pixi i --skip`) via manifest

[jstriebel]

Problem description

Having the options to (un-)select specific packages introduced in #4404 is great! I'd like to consistently (un-)select specific transitive dependencies which are not needed, without replicating full packages on a custom channel. To do this consistently, I would like to be able to specify them in the pixi.toml manifest. Preferably, the excluded packages should also be removed from the lockfile, or marked specifically there as "not installed".

[lucascolley]

would you be interested in this for conda deps, PyPI deps, or both?

[jstriebel]

I'm only interested in conds deps. For PyPI deps this is less of an issue, as library authors can use extra dependencies for optional dependencies. (I don't think there's a similar concept for conda packages?). This matches the scope of #4404, see description there:

PyPI filtering is unused until we implement ignore for the PyPI installer as well.

My main concern is to have sth. like the --skip/--skip-with-deps install options available in a consistent declarative way.

[lucascolley]

library authors can use extra dependencies for optional dependencies. (I don't think there's a similar concept for conda packages?)

Yeah not really (yet), but you can have multiple outputs from one feedstock, like https://github.com/conda-forge/scipy-stubs-feedstock/blob/main/recipe/recipe.yaml. They just need to have different names.

We do have a proposal for bringing extras to the conda world at conda/ceps#111.

[jstriebel]

We do have a proposal for bringing extras to the conda world at conda/ceps#111.

Very nice! Lookinf forward to it being adapted!

PS: I just checked for uv, the proposal there is to set sys_platform == 'never' for PyPI packages, see astral-sh/uv#9174 (comment). If a similar method works for pixi I'd find that a usable workaround.

[tdejager]

I was thinking this might also be good as a pixi extension. I mean the first proposal, not the optional dependencies. Don't think we will get to it soon though.

[effigies]

A similar feature recently landed in uv: astral-sh/uv#16528

Previously you could override the dependency with an extra like flask ; python_version < '0'. However, pixi's dependency-overrides doesn't allow qualifiers on version specifiers like that. I would be very interested in this for PyPI as well as conda, as there are a number of packages I use that do not use optional dependencies to gate subsets of behavior.

[tdejager]

Hey @effigies the original comment talked about the installation exclusively. But you are talking about excluding it from the solve as well. Could you give an example of how you would like this to look in the toml?

With uv supporting this this would be technically feasible for PyPI at least and possible for conda.

[effigies]

Looks like uv uses a top-level:

[tool.uv]
exclude-dependencies = ["werkzeug"]

We could do a similar thing:

[tool.pixi]
# Ensure werkzeug doesn't get pulled in by conda or PyPI dependencies
exclude-dependencies = ["werkzeug"]
exclude-pypi-dependencies = ["werkzeug"]

I think it is similar in kind to channel-priority and solve-strategy, so it could also be overridden extended (I think it would be too confusing for a feature to remove exclusions) under features.

---

As to solve vs install, I think that's an interesting question. You could imagine a solve group where one of the environments has a feature that excludes a package and one doesn't, so the package would still need to be taken into account if it is not excluded from all environments in the solve group. That could be useful for having a fully-featured dev environment and a minified production environment where the only difference is the removal of packages known not to be accessed.

[tdejager]

Yeah solve-groups make it more difficult cause in that sense you have to interpret it it as install-only exclusion. While when its not part of a solve-group you can potentially exclude it from the solve altogether basically unlocking that constraint. Which I assume was part of the original reason for that feature in uv?