Install development dependencies incrementally

[nealstewart]

Checklist

• I added a descriptive title
• I searched open requests and couldn't find a duplicate

What is the idea?

I use conda-lock to lock versions before building Docker images, and also to create a local development environment. With conda-lock's development dependencies, I can create a fresh conda environment with said dependencies, but I would like to be able to update an existing conda environment seamlessly to do so and include pip dependencies that are locked.

Why is this needed?

Essentially this would just support staged Docker builds without adding egregious amounts of time to my build in order to install with conda-lock twice.

What should happen?

conda-lock install --no-dev -n example
conda-lock install --dev -n example # Incrementally installs the development. dependencies

Additional Context

No response

[maresb]

I use it similarly and would really like to see this. In particular it would be great if conda-lock install didn't clobber existing environments, but rather diffed with the existing dependencies in order to figure out the necessary changes.

Another potentially nice usage case along these lines with Docker would be, in the case of large environments, to apply sequences of lockfiles in order to avoid a full rebuild, e.g.

COPY conda-lock-01.yml .
RUN conda-lock install conda-lock-01.yml
COPY conda-lock-02.yml .
RUN conda-lock install conda-lock-02.yml
...

@nealstewart, would you be willing to contribute a PR?

[nealstewart]

@maresb PR incoming...

[nealstewart]

I've implemented it as an optional new flag --update, in order to preserve the existing API behaviour (install twice, create two environments).

I just leverage conda env update behind the scenes to leverage Conda's existing behaviour.

[nealstewart]

There you go!

[sjdemartini]

As mentioned in #516 (comment), this would be useful not just for development dependencies, but it would be super useful in general to be able to update an existing env to match a lockfile, rather than deleting/recreating the env entirely as seems to happen now. The latter approach is unsafe for any shared environments (e.g. a JupyterHub kernel env), but conda-lock would be very useful there for updating environments predictably.