Open jacobj45 opened 5 months ago
You can already import an environment.yml during init via pixi init —import
Thanks, could not find any references to this while going through the docs.
Does this command also work with requirements.txt
?
Nope, it does not sorry.
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!
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.
@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:
environment.yml
as a new environment within an existing project? My impression so far is 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.
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?
I could imagine we support
--import
onpixi 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 ...
?
@ctrueden I like that option :-)
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.
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:
Description
It would be great to have a command that can create new Pixi environments from existing
requirements.txt
(pip) orenvironment.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.