Tests for packages with features fail

[Zaharid]

I have a packgage called nnpdf_use_double, which tracks a feature of the same name. The meta.yaml is copied from the documentation:

package:
  # This name doesn't have to be the same as the feature, but can avoid confusion if it is
  name: nnpdf_use_double
  # This need not relate to the version of any of the packages with the
  # feature. It is just a version for this metapackage.
  version: 1.0

build:
  track_features:
      - nnpdf_use_double

When I try to build a package that depends on this feature, I cannot get past the tests:

package:
  # This name doesn't have to be the same as the feature, but can avoid confusion if it is
  name: xxx
  # This need not relate to the version of any of the packages with the
  # feature. It is just a version for this metapackage.
  version: 1.0

build:
  features:
      - nnpdf_use_double

test:
    requires:
        - python
    imports:
        - collections

Conda build fails with the error:

$ conda build xxx 

Removing old build environment
BUILD START: xxx-1.0-nnpdf_use_double_0
Package: xxx-1.0-nnpdf_use_double_0
no source
number of files: 0
Fixing permissions
Fixing permissions
BUILD END: xxx-1.0-nnpdf_use_double_0
TEST START: xxx-1.0-nnpdf_use_double_0
Using Anaconda Cloud api site https://api.anaconda.org
Fetching package metadata: ............
Solving package specifications: ....
Error: The following specifications were found to be in conflict:
  - xxx 1.0 nnpdf_use_double_0
Use "conda info <package>" to see the dependencies for each package.

[msarahan]

Add your track feature metapackage to your test: requires: section. You
have to activate features by installing something that tracks the feature.

On Conda-Forge, people are using a "vc" metapackage to activate the
appropriate vc feature. It is much nicer than activating that feature with
python implicitly. An example using it is at
https://github.com/conda-forge/python-feedstock/pull/19/files

On Tue, Jun 14, 2016 at 1:23 PM, Zaharid notifications@github.com wrote:

I have a packgage called nnpdf_use_double, which tracks a feature of the
same name. The meta.yaml is copied from the documentation:

package:

This name doesn't have to be the same as the feature, but can avoid confusion if it is

name: nnpdf_use_double

This need not relate to the version of any of the packages with the

feature. It is just a version for this metapackage.

version: 1.0

build:
track_features:
- nnpdf_use_double

When I try to build a package that depends on this feature, I cannot get
past the tests:

package:

This name doesn't have to be the same as the feature, but can avoid confusion if it is

name: xxx

This need not relate to the version of any of the packages with the

feature. It is just a version for this metapackage.

version: 1.0

build:
features:
- nnpdf_use_double

test:
requires:
- python
imports:
- collections

Conda build fails with the error:

$ conda build xxx

Removing old build environment
BUILD START: xxx-1.0-nnpdf_use_double_0
Package: xxx-1.0-nnpdf_use_double_0
no source
number of files: 0
Fixing permissions
Fixing permissions
BUILD END: xxx-1.0-nnpdf_use_double_0
TEST START: xxx-1.0-nnpdf_use_double_0
Using Anaconda Cloud api site https://api.anaconda.org
Fetching package metadata: ............
Solving package specifications: ....
Error: The following specifications were found to be in conflict:

• xxx 1.0 nnpdf_use_double_0
  Use "conda info " to see the dependencies for each package.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#1026, or mute the thread
https://github.com/notifications/unsubscribe/AACV-SiL91iRCLHKmB5h1LV9JjgntAY4ks5qLvGagaJpZM4I1naZ
.

[Zaharid]

Thanks, this makes it work. Would be nice to have this in the docs. Also, should it be a run dependency rather than a test, in case I had those?

In any case, I am not sure about this behaviour: Surely a package should never be incompatible with itself!

[msarahan]

Sure, a run dependency would work, too, and is probably the right choice.

I find this behavior extremely unintuitive myself, and will be working over time to make this simpler. Sorry for the confusion. I'm glad you came up with the metapackage idea. Trying to do this without metapackages is even harder to get to work!

[Zaharid]

I think this is yet another example where having a command:

conda install-the-package-contained-in-this-file-and-set-ITS-dependencies .tar.bz2

would help. Then you could have that set the appropriate features for e.g. the test environment.

Because it seems to be that the use case for features is to have versions of packages with and without them (otherwise there is a simple requirement), I'd say the API could look like:

meta.yaml:

....
available_features:
   - debug
   - profile

which does nothing by default. But when you do:

conda build my_package --features debug

It sets a matching environment variable for the build script, like FEATURE_DEBUG=1. The more interesting part would be:

conda build my_package --features-matrix

which would build all available combinations. For tracking features I would simply have

conda track <arbitrary identifier>

and the corresponding API to list, untrack and so on (which would be equivalent to managing the metapackage but without somebody having to bother to build and upload an empty metapackage in the first place).

[msarahan]

We'll have matrix stuff like this as part of #966 - there will be features, pinning, and whatever you want, all done with jinja2 and configurable in a yaml file.

CC @kalefranz about the install issue.

[github-actions]

Hi there, thank you for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs.

If you would like this issue to remain open please:

1. Verify that you can still reproduce the issue at hand
2. Comment that the issue is still reproducible and include:
   - What OS and version you reproduced the issue on
   - What steps you followed to reproduce the issue

NOTE: If this issue was closed prematurely, please leave a comment.

Thanks!