Staged-recipes: Gstreamer is now offered in the main conda repo, can the forge version be removed?

[matham]

So I ran into an issue with gstreamer and gst-plugins-base. They are both available on defaults and on conda-forge. The problem is that the one on forge, only has packages for linux-64 while the anaconda package is available for linux and osx. In addition, the anaconda package is much newer (the newest version in fact) while the forge one is old.

The reason this is a problem, is that I need gstreamer and gst-plugins-base as a dependency for kivy (https://github.com/conda-forge/staged-recipes/pull/5966) on osx. But it's not finding it, even though it's offered by anaconda, likely because it sees that forge also offers it, but then upon finding that it doesn't have a version for osx, it errors out rather than checking anaconda next.

Would it be possible to remove the forge version of these repos?

https://anaconda.org/conda-forge/gstreamer
https://anaconda.org/conda-forge/gst-plugins-base
vs.
https://anaconda.org/anaconda/gstreamer
https://anaconda.org/anaconda/gst-plugins-base

[asmeurer]

This doesn't sound like the correct reason for what happened. Conda only looks at the repo for the platform it is on. The existence or nonexistence of Linux packages should have no effect on osx. Does conda-forge perhaps just remove defaults from the channel config, to force everything to come from conda-forge? If both channels are included what you are describing should work.

At any rate, why do you want to remove conda-forge packages? Shouldn't the correct action here be to update the packages, and build osx versions?

[matham]

On Tue, May 29, 2018, 12:57 PM Aaron Meurer [e-mail]
wrote:

This doesn't sound like the correct reason for what happened. Conda only
looks at the repo for the platform it is on. The existence or nonexistence
of Linux packages should have no effect on osx. Does conda-forge perhaps
just remove defaults from the channel config, to force everything to come
from conda-forge? If both channels are included what you are describing
should work.

I can see conda listing in the packages that it will install that some come
from conda and others from forge so it must have access to both?

At any rate, why do you want to remove conda-forge packages? Shouldn't the
correct action here be to update the packages, and build osx version

I suppose so. It's that I saw that there's a pull request and issues on the
forge repo from a couple if years so I figured it probably isn't maintained
anyway. Also. The defaults repo is a fork of the forge repo (...) and that
one is continually maintained. I could make a PR from the conda to the
forge repo, but isn't it better to just drop the forge one? It must have
been created before it was originally in conda, see that its a fork?

[asmeurer]

I can see conda listing in the packages that it will install that some come
from conda and others from forge so it must have access to both?

Someone from the core team will need to clarify what is going on here. Does the staged-recipes build force all dependencies to come from conda-forge? Or maybe the defaults versions are there but they can't be installed because of some other incompatibility.

I suppose so. It's that I saw that there's a pull request and issues on the
forge repo from a couple if years so I figured it probably isn't maintained
anyway. Also. The defaults repo is a fork of the forge repo (...) and that
one is continually maintained. I could make a PR from the conda to the
forge repo, but isn't it better to just drop the forge one? It must have
been created before it was originally in conda, see that its a fork?

The conda forge recipes are maintained by the community. If a feedstock hasn't been getting the attention it needs, you should ping the recipe maintainers. If they don't respond, ping the core team and they can try to find someone to help maintain it (or you can volunteer to do it yourself).

The goal of conda-forge is to package everything, not to just package things that haven't been packaged by Anaconda.

The defaults channel is maintained by Anaconda, whereas the conda-forge channel is maintained by the community. It might not make a difference to you as an end-user of the packages, but it makes a big difference to the package maintainers and the community. Consider for instance if the reverse were the case, if the Anaconda/defaults package were out of date. Updating it would require getting someone from Anaconda to update it. This is not necessarily difficult—Anaconda is a friendly enough company—but if it's low on their priority list it may be difficult to do without paying them. In conda-forge, if you really needed it done, you could just do the work yourself by making a PR to the feedstock.

This talk by Phil Elson explains why community packaging is important, even though Anaconda also provides the same service.

Note, I have nothing against Anaconda. I am simply pointing out that the Anaconda repos and the conda-forge repos serve different purposes and hence can and should co-exist with one another.

[jakirkham]

Can't say why you aren't finding them, but that has nothing to do with conda-forge. It likely has something to do with how channels are set in your .condarc. So would take a look at that. Most likely anything fishy here will be a conda issue not a conda-forge one. That problem is outlined in this comment.

@asmeurer, did a great job answering everything else. So will leave it at that unless there are other specific questions.

[asmeurer]

@jakirkham unless I am mistaken I think @matham is referring to the build failures at https://github.com/conda-forge/staged-recipes/pull/5966.

[jakirkham]

Right, let's discuss build failures in that PR to keep things easy to follow.

[jakirkham]

Have outlined the cause of the failure in this comment. Here are some relevant docs.