Ideas to support conda-lock

[ccordoba12]

In #5 (comment), @dalthviz said

The thing with conda-lock is that from what I tested is meant to be used passing to it a .yml (I would say that usually manually created). With that, conda-lock then creates a file with the respective constraints and OS specific packages

Right, that's also what I understood from its Readme. Then, I think we need to create that yaml file on behalf of users. For that we could do the following:

1. Ask users on Spyder what packages they would like to install/add/remove from their environments (using a QDialog and a QTableView, for instance).
2. Use that information to create/update the environment.yml needed by conda-lock.
3. Run conda-lock lock --file <path-to-env-file> --lockfile <path-to-lock-file> to generate/update the lock file.
4. Run conda-lock install --prefix <path-to-conda-env> to create/update the associated conda env.

Steps 2. to 4. could be done here, I'd say. (Note: I got these CLI options from https://conda-incubator.github.io/conda-lock/cli/gen/).

With that idea in mind, I also propose to:

• Save both the environment.yml and conda.lock files per environment in a special, hidden directory declared by this package.
• Create environments in a special directory called ~/spyder-envs (or something similar).

I think we'd need to do that because right now we don't have a way to associate envs to projects. So, initially we'd only offer a simple way to create environments.

Finally, I think the import/export functionality for conda-lock could work like this:

1. Exporting would consist in allowing users to save the environment.yml for a certain env at a specific location (i.e. out of the special config directory of this package). For that maybe we'd need to add a menu entry to our main menu called Environments that allows users to easily export/import env yaml files.
2. At import time we'd need to pass a user selected environment.yml file to this package and use conda-lock to run steps 3. and 4 above (i.e. conda-lock lock and conda-lock install).

[dalthviz]

Following the ideas proposed then things to add here are:

• Signatures to enviroment_file, environment_lock, and environment_from_lock (for example) for the API
• Implementation of those signatures for the conda-like backend (which will depend on the conda-lock executable being installed somewhere, probably as a dependecy of the actual Spyder plugin that will use this package or as an optional dependency of this package).

And things to add to the actual Spyder plugin (spyder-env-manager)

• A way to get the information for the environment.yml file with just the requested packages by the user
• Define where to create environments.
• Way to request importing/exporting a file

Regarding the import input and export output you mean that the user will use the environment.conda-lock.yml, right?

[ccordoba12]

Signatures to enviroment_file, environment_lock, and environment_from_lock

I suggest to change environment_lock to environment_lock_file.

Regarding the import input and export output you mean that the user will use the environment.conda-lock.yml, right?

Yeah, I think so, so that envs are fully reproducible for other users that import the env file on their computers. However, given that environment.conda-lock.yml doesn't have the list of packages required to update or install other packages in the env, perhaps we'd need to package both environment.conda-lock.yml and environment.yml in a zip file so that users can keep working with the env after importing it.