from-env subcommand for creating lock files from existing environments

jjhelmus commented 1 year ago

This is a rough version of a new from-env subcommand that creates a lock file from an existing conda environment.

I wanted to submit the change in this form to see if there was interest in such a feature and to collected feedback on the approach. If this is something that would be accepted into conda-lock, I'd be happy to continue working on the change to get it into a more complete state.

netlify[bot] commented 1 year ago

Deploy Preview for conda-lock ready!

Name	Link
Latest commit	5d4078644b2e340c1ee8f8afb4415e4e8910910b
Latest deploy log	https://app.netlify.com/sites/conda-lock/deploys/654d087986acce0008bf7031
Deploy Preview	https://deploy-preview-445--conda-lock.netlify.app/cli/gen
Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

jjhelmus commented 1 year ago

An example of the new subcommand:

❯ conda create --prefix ./example python=3.10 numpy
...
❯ conda-lock from-env --prefix ./sample 
 - Install lock using: conda-lock install --name YOURENV conda-lock.yml
❯ head -40 conda-lock.yml
# This lock file was generated by conda-lock (https://github.com/conda/conda-lock). DO NOT EDIT!
#
# A "lock file" contains a concrete list of package versions (with checksums) to be installed. Unlike
# e.g. `conda env create`, the resulting environment will not change as new package versions become
# available, unless you explicitly update the lock file.
#
# Install this environment as "YOURENV" with:
#     conda-lock install -n YOURENV --file conda-lock.yml
# To update a single package to the latest version compatible with the version constraints in the source:
#     conda-lock lock  --lockfile conda-lock.yml --update PACKAGE
# To re-solve the entire environment, e.g. after changing a version constraint in the source file:
#     conda-lock  --lockfile conda-lock.yml
version: 1
metadata:
  content_hash: {}
  channels:
  - url: defaults
    used_env_vars: []
  platforms:
  - osx-arm64
  sources: []
package:
- name: ca-certificates
  version: 2023.05.30
  manager: conda
  platform: osx-arm64
  dependencies: {}
  url: https://repo.anaconda.com/pkgs/main/osx-arm64/ca-certificates-2023.05.30-hca03da5_0.conda
  hash:
    md5: 323db96c02c0e6ee266388ad4be3f762
    sha256: 98ad45e8ca832f8b9ee0faabc8791ff9d6488d9d2d0b5106038f7bad6d712436
  category: main
  optional: false
- name: libcxx
  version: 14.0.6
  manager: conda
  platform: osx-arm64
  dependencies: {}
  url: https://repo.anaconda.com/pkgs/main/osx-arm64/libcxx-14.0.6-h848a8c0_0.conda
  hash:

maresb commented 1 year ago

Thanks a lot for this! Looks very interesting.

I'm very curious what is the motivation and what this accomplishes that conda env export doesn't.

AlbertDeFusco commented 1 year ago

I like this approach over conda env export in that the architecture is stated in the lock file. If someone gives you the output of conda env export it's not immediately apparent what platform that was created from.

And if the conda env export --from-history output is retained along side the single-platform lockfile you could solve for other platforms while keeping the original platform lock fixed.

conda / conda-lock