Staged-recipes: `noarch` with dep(s) not built on all systems

[CJ-Wright]

What is the policy on noarch builds which have dependencies that are not built for all systems? Are these valid noarch recipes?
Attn: @scopatz
@conda-forge/staged-recipes

[CJ-Wright]

It would be nice to not propagate dependency OS specific build issues up through all the dependency graph.

[scopatz]

I think it is OK to have noarch packages whose dependencies don't exist on all platforms at the time when the recipe is built. The dependency may be added to a platform in the future, and the noarch package will work with no further human intervention.

[jakirkham]

What sort of failure does conda give if someone tries to install this noarch package with missing dependencies? Even a dummy example would be productive for understanding this behavior.

[djsutherland]

If you make a noarch package depending on a package only available on a different python version, where here stupid-dummy-dep is a noarch package depending on enum34 but trying to be installed on python 3.6:

UnsatisfiableError: The following specifications were found to be in conflict:
  - python 3.6*
  - stupid-dummy-dep -> enum34 -> ordereddict -> python 2.6*
Use "conda info <package>" to see the dependencies for each package.

If you make a noarch package with a dependency only available on a different architecture, where here stupid-dummy-maconly is a noarch package, stupid-dummy is a package only available on Mac (sorry for bad names, they should probably be swapped), and I'm trying to install it on Linux:

PackageNotFoundError: Packages missing in current channels:

  - stupid-dummy-maconly -> stupid-dummy

We have searched for the packages in the following channels:
[...]

Pretty informative error messages, IMO, which makes me 👍 for allowing this.

[jakirkham]

Agreed. Thanks for experimenting with this, @dougalsutherland.

[CJ-Wright]

Awesome! I guess this needs some docs somewhere?

[scopatz]

probably the docs repo :)

[scopatz]

Though an additional comment in the example would be good too.

[jakirkham]

I think we resolved this satisfactorily. Happy to close @CJ-Wright?

[CJ-Wright]

Yes, although I was going to keep this open until the docs got written.

[jakirkham]

Ah sorry. Missed the other doc point. Yeah feel free to keep this open if it helps you.

[mbargull]

How would you be able to get this through the selector linting on staged-recipes? On the feedstock you can do a rerender and thus won't need a selector with missing Windows dependencies. Is it currently possible to make this use case work for new recipes on staged-recipes?
Very recent example: https://github.com/conda-forge/staged-recipes/pull/4860.

[mbargull]

Would you have to use [skip appveyor] commit messages?
(EDIT: Nvm, found https://github.com/conda-forge/staged-recipes/pull/4724. Should the [skip appveyor] necessity also be added to the example recipe's text?)

[djsutherland]

@mbargull Right, just don't put skip: true  # [win]. [skip appveyor] in the commit message avoids running it on Windows where it won't work anyway, but if you didn't do that we would also be able to just ignore the red X. :)

[mbargull]

we would also be able to just ignore the red X. :)

I tend to forget that "human factor" -- thanks for reminding me 😄.
If you think it's reasonable, I'd suggest to put a note on [skip appveyor] when the docs are added.

[jakirkham]

Closing as this is now documented thanks to PR ( https://github.com/conda-forge/conda-forge.github.io/pull/567 ).

Thanks everyone :)