optional dependencies #4982
optional dependencies #4982
Conversation
kalefranz
force-pushed
the
optional-dependencies
branch
from
bd836bd
to
2b93313
Compare
|
I like Debian's wording of 👍 for this new feature, this is really much needed. Will there also be a possibility to specify "optional" for |
There could be I guess, but I don't really understand the use case, or what it would actually do. Could you elaborate on how you'd use it? Something maybe related that is coming is the ability to specify pinned dependencies within condarc configuration files. The ability is actually in the 4.3.16 release that's in canary right now, but marked as a beta feature. The difference is that, in 4.4, these will be the optional type dependencies that constrain versions only if the package is installed, whereas in 4.3 these pinned specs act as hard dependencies and force the package into the environment. |
When setting up a testing environment In CI (appveyor/Travis), we first install our hard dependencies, some of which with fixed versions differing across the build matrix. After that we'd like to try to install some optional dependencies to also cover some tests that can only run with certain packages installed. But we don't want those install commands to alter previously installed package versions, just try to install them if they can fit in the current set of installed packages. I know, this could and maybe should be done using |
kalefranz
force-pushed
the
optional-dependencies
branch
from
2b93313
to
6d6e568
Compare
| result = {ms.name: ms for ms in (MatchSpec(spec) for spec in self.depends or ())} | ||
| result.update({ms.name: ms for ms in (MatchSpec(spec, option=True) | ||
| for spec in self.constrains or ())}) | ||
| return tuple(itervalues(result)) |
There was a problem hiding this comment.
@mcg1969 This is the only logic I've added to this PR beyond yours, as we discussed today. Is using a dict to dedupe by name the best way to do this here? Do you have other ideas?
There was a problem hiding this comment.
Well, rule number one is that you shouldn't de-dupe if you don't have to, because multiple MatchSpecs with the same name has semantic meaning. So let's make sure you're not doing it in other places. Here, we want the constraints to overwrite the depends. In the absence of duplicates in either list, this is the right way to do it. Do we want to allow dupes in conda recipes? I'd say not. So this should be good. Certainly for now...
|
Hi @kalefranz how will this feature be mapped to meta.yaml? I have a PR in conda-forge/staged-recipes#2882 for Airflow 1.8 that could make use of that syntax. |
|
The conda-build PR for enhancement to meta.yaml is conda/conda-build#2001. Under the It's merged for conda-build 3, which I think @msarahan has plans to release the rc0 is the coming days. It'll also only be supported for users running conda >=4.4, which is close to being ready to release into canary. |
|
Will it be possible to make these dependencies install by default with the package and simply prevent conda from disallowing them from being uninstalled? |
* Document instructions for minmal dask-core install This pull request's core purpose is to add in instructions for installing dask-core which has less dependency bloat than the default `conda install dask`. A use-case for example is for developers building docker images that don't want a overly huge image size (see e.g. [here](https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#avoid-installing-unnecessary-packages)), or for those who would like to manage the optional dependencies themselves. Aware of #2336 which removes confusion of two channels (default and conda-forge), but seeing as dask-core downloads overwhelming come from the conda-forge channel (>30k vs < 100 see https://anaconda.org/search?q=dask-core), I thought I'd add back in the instructions for conda-forge, but add in 'recommended' in brackets next to default channel so that new users won't be too confused. Open to recommendations on what's better. External references: https://pypi.python.org/pypi/dask conda/conda#4982 (note new optional dependency functionality from conda 4.4.0 onwards) conda-forge/dask-feedstock#22 * Retain only link to conda-forge Remove `conda install -c conda-forge` so as to not add extra confusion, as per #2336. Using KISS philosophy. * Fix up some more small style and english issues.
|
Hi there, thank you for your contribution to Conda! This pull request has been automatically locked since it has not had recent activity after it was closed. Please open a new issue or pull request if needed. |
For the 4.4.0 release, this PR supersedes #4120. It leaves out the package superseding part of #4120.
This feature will allow a package to restrict versions of other packages installed within its environment, while also not forcing those packages to be installed. That is, these are not hard dependency specifications, but the constraints of "optional" dependencies.
We need a keyword here to add to a package's metadata for this feature. The value will be a list of matchspec strings, just as
dependsis a list of matchspec strings.Possibilities for this keyword include
This PR needs the new MatchSpec object in #4158. The envs PR #4676 will follow this one.