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

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]

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.

[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.