On Jul 22, 2016, at 11:47 AM, Chris Barker - NOAA Federal <chris.barker@noaa.gov> wrote:
If the core devs think it's fine and dandy like it is, we can all stop talking about it.
I think they’re certainly a problem. The current solutions that have been proposed have their own problems of course, and problems enough that I don’t feel comfortable implementing them. Personally I don’t currently have the time to work on a better solution but if someone did that’d be fine with me. I would mention though that it’s possible there *is* no solution to this problem that doesn’t bring with it it’s own problems that are worse then the problem at hand. I’m not saying that’s the case, but just mentioning that it may be so.
By the way, there is an experiment underway with a "curated" community package repository for conda packages:
It's semi-curated, in the sense that only the core devs can approve a package being added, but once added, anyone can maintain it.
It's going very well, but I'm not sure how it's going to scale. So far, 900 or so packages, 80 or so maintainers. Which I think is very impressive for a young system, but still a lot smaller than it could be.
But I think PyPA should keep an eye on it -- I'm sure there will be lessons learned.
conda-forge and PyPI are not really similar. For conda-forge they’re largely just repackaging other software for the conda system. This makes it function better when you have just anyone of the core team able to work on stuff, because all they’re doing to adjusting the build, upgrading versions etc. They’re not working on the projects themselves. Curated also goes against the sort of “spirit” of PyPI. It’s a place where anyone can release something and immediately be able to be part of the ecosystem. Adding curation on top of that would change the nature of PyPI, maybe for the better or maybe for the worst, but it would fundamentally change PyPI. — Donald Stufft