Command to create new Pixi environments from `requirements.txt` or `environment.yml` files

[jacobj45]

Description

It would be great to have a command that can create new Pixi environments from existing requirements.txt (pip) or environment.yml (conda) files.

Motivation

Having such a command would make it easier for existing projects that use these files for dependency management to migrate to Pixi.

[olivier-lacroix]

You can already import an environment.yml during init via pixi init —import

[jacobj45]

Thanks, could not find any references to this while going through the docs.

Does this command also work with requirements.txt?

[olivier-lacroix]

Nope, it does not sorry.

[ruben-arts]

Linking this to a discord chat: https://discord.com/channels/1082332781146800168/1261794228460195910

For those reading this, we would also like to support requirements.txt like we do with environment.yml.

Which means reading requirements.txt files during the pixi init --import requirements.txt. This being PyPI dependencies this should automatically add a python dependency as well and move all the requirements to [pypi-dependencies]. This could be extended in the future with smarter conda-pypi mapping logic. But lets keep the initial pr simple with the inclusion of the requirements.txt reading.

@kaweees mentioned in Discord he wanted to give this a go, please do!

[roaldarbol]

In case pixi init --import fails due to the strict channel priority, it would be great if it falls back to disabling the strict channel priority. The ability to disable the strict channel priority has already been implemented in rattler (https://github.com/mamba-org/rattler/pull/598), but not yet exposed in pixi (https://github.com/prefix-dev/pixi/issues/1254), so when it gets implemented it could be added to --import as well.

[ctrueden]

@jacobj45 Could you clarify the intended scope of this issue? I'm new to pixi, but from what I understand so far, pixi init --import creates a new pixi project with one new default environment matching the given environment.yml. But even if that environment.yml defines the name with, say, name: spiffy, the resultant environment in the newly formed pixi project will always be named default.

So my questions are:

• Is there currently a way to import an environment.yml as a new environment within an existing project? My impression so far is no.
• If not: the phrasing of this issue suggests the desire to have such a feature, no?

I ask because all the discussion above is focused on creating new pixi projects from requirements.txt files, but no discussion of multiple environments for a particular pixi project.

[ruben-arts]

Hi @ctrueden, good question. This issue was indeed always looked at from the project idea. But I agree it would be awesome to have an import command on an existing project! I haven't giving this much though yet but I could imagine we support --import on pixi add.

@olivier-lacroix what do you think of that?

[ctrueden]

I could imagine we support --import on pixi add.

What about a new toplevel command pixi import with optional --environment flag to set/override the destination environment name? And the existing pixi init --import ... could keep the current behavior, which would be essentially a shorthand for pixi init; pixi import --environment default ...?

[olivier-lacroix]

@ctrueden I like that option :-)

[maresb]

I just used conda-lock's source parsing capabilities to create a pixi.toml generator that works for environment.yml, pyproject.toml, and multiple combinations thereof. I'm planning to release it soon as part of conda-lock, but for now it's only available on the main branch.

You can get it with:

pipx install --force git+https://github.com/conda/conda-lock@main

You can generate a pixi.toml by running a command like the following:

conda-lock render-lock-spec --kind=pixi.toml --stdout \
  --file=environments/dev-environment.yaml \
  --file=pyproject.toml \
  --pixi-project-name=conda-lock \
  --editable conda-lock=. \
  > pixi.toml

You can view the result here.

This should hopefully work in general with almost any pyproject.toml or environment.yml. Just run a command similar to the above and pixi should be ready to go. You don't need to be a previous conda-lock user to migrate projects with it.

[maresb]

I threw together a quick draft of a migration guide in https://github.com/conda/conda-lock/pull/708: preview link.

I'm hoping to use this technique to migrate a bunch of projects to pixi. I hope it can help others do the same!

I'm very eager to get feedback :grin:

[aegroto]

Looks like pixi add --pypi $(cat requirements.txt) does the trick, although having specific support for requirements.txt files would be better.

[stefanv]

Perhaps relevant here as well: dependency groups.

[lucascolley]

A few things that may be worth supporting here:

• pixi init --import requirements.txt
• pixi add --file environment.yml
• pixi add --file requirements.txt (gh-2206)

[lucascolley]

we are now considering a new subcommand pixi import for commands such as pixi import --pypi requirements/test.txt, pixi import --conda environment.yml. This would be instead of pixi add --file but would still support directing the imported dependencies to existing features/environments, as well as creating new ones.

Please chime in at https://github.com/prefix-dev/pixi/issues/4085 if you have any specific feedback/concerns regarding the CLI!

pixi init --import requirements.txt could still be supported separately, but would probably re-use similar logic to pixi import --pypi.

[lucascolley]

Roadmap for related work: https://github.com/prefix-dev/pixi/issues/4192

[lucascolley]

I think we can close this issue on the merge of gh-4270, at which point we will have both pixi import --format=conda-env and pixi import --format=pypi-txt! There will be some further edge cases and follow-ups still tracked in gh-4192.