Getting to this thread late, but it didn't seem that was resolved in the least, so I'll as my $0.02
> That overall got me thinking about namespace pollution in pip, that > once something is pushed in, it's like to stay there forever. This REALLY is a problem, and one that will only get worse. It would be nice to work out an approach before it gets too bad. > I'd rather see something similar to Linux distributions where there's > a curated repository "core" As pointed out, that's not going to happen. > and a few semi-official, like "extra" and > "community," and for some, "testing." But namespaces like these could still be implemented without curation. Right now, the barrier to entry to putting a package up on PyPI is very, very low. There are a lot of 'toy', or 'experimental', or 'well intentioned but abandoned' projects on there. If there was a clear and obvious place for folks to put these packages while they work out the kinks, and determine whether the package is really going to fly, I think people would use it. And we could have mostly-automatic policies about seemingly abandoned projects as well -- moving them to the "unmaintained" channel, or.... As for the 'deadman's switch' idea -- that's a great idea. Sure, there are projects with no active maintainer that people rely on, but almost be definition, if folks care about it, we'd be able to find someone willing to put their finger on the dads man's button once a year.... As for issues like setuptools and PIL, where there is a shift in maintenance if a large, high profile package, we really need a benevolent oligarchy for PyPA that can resolve these issues by hand. As pointed out -- this really doesn't come up often. However, in these discussions, I've observed a common theme: folks in the community bring up issues about unmaintained packages, namespace pollution, etc. the core PyPA folks respond with generally well reasoned arguments why proposed solutions won't fly. But it's totally unclear to me whether the core devs don't think these are problems worth addressing, or think they can only be addresses with major effort that no one has time for. If the core devs think it's fine and dandy like it is, we can all stop talking about it. By the way, there is an experiment underway with a "curated" community package repository for conda packages: https://conda-forge.github.io 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. -CHB > A name foobar resolves to core/foobar-<latest> if that exists, and if > not some subset of other repositories is used. > This way, an outdated package can be moved to another repo without > breaking install base. > > In fact, curation without namespaces will already be pretty good. > > d. > >> On 13 July 2016 at 19:24, Jim Fulton <j...@jimfulton.info> wrote: >>> On Tue, Jul 12, 2016 at 7:55 AM, Dima Tisnek <dim...@gmail.com> wrote: >>> Hi all, >>> >>> Is anyone working on pruning old packages from pypi? >>> >>> I found something last updated in 2014, which, looking at the source >>> appears half-done. >>> Github link doesn't work any longer, no description, etc. >>> >>> I managed to find author's email address out of band, and he responded >>> that he can't remember the password, yada yada. >>> >>> I wonder if some basic automation is possible here -- check if url's >>> are reachable and if existing package satisfies basic requirements, >>> failing that mark it as "possibly out of date" >> >> I'm curious why you view this as a problem that needs to be solved? >> >> - Do you want to take over the name yourself? >> >> - Are you afraid someone will stumble on this package and use it? >> >> Something else? >> >> Jim >> >> -- >> Jim Fulton >> http://jimfulton.info > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
