<div dir="ltr">We've been discussing here at least two different problems related to package maintainership:<div><br></div><div>1. Abandoned/no-longer-maintained, but previously useful packages</div><div><br></div><div>2. namespace and package idea space pollution due to tests/aborted attempts/packaginginexperience.</div><div><br></div><div>I don't have a good idea about 1, and it's clear from this discussion that curation as a solution for 2 is currently non-workable/undesirable due to both lack of manpower and a desire not to discourage contributions.</div><div><br></div><div>Even if curation is not involved, we also don't want to up the barrier to entry such that we discourage new entrants into the ecosystem.</div><div><br></div><div>A level of namespacing on the project name (but not (necessarily) on the python module/package level) was suggested as a way to reduce 2.</div><div><br></div><div>I just thought of another, orthogonal, suggestion for 2:</div><div><br></div><div>There is a TestPyPI server but it feels like few people use it (I certainly never did).</div><div><br></div><div>What if you were only allowed to push a new project onto PyPI proper if you already have similarly named project on TestPyPI and at least one release of that project there?</div><div><br></div><div>Notice that I'm not suggesting that all files need to touch TestPyPI before going to PyPI, although that could be considered in the future.</div><div><br></div><div>I'm also not suggesting a waiting period between publishing on TestPyPI and PyPI, but this could also be considered if we see people abusing the fact that dumping some garbage on TestPyPI is the only step necessary before dumping some garbage on PyPI.</div><div class="gmail_extra"><br></div><div class="gmail_extra">And we could make it so TestPyPI is a bit more flexible with files than PyPI itself. For instance we could allow deletion and re-upload of files with the same name there that is currently disallowed on PyPI so people can test-drive their releases before pushing  files onto PyPI proper (don't know if this is already the case).</div><div class="gmail_extra"><br></div><div class="gmail_extra">"Hey!" I hear you saying "If we're just moving the namespace reservation from PyPI to TestPyPI" aren't we just moving problem number 2 around without really solving it?"</div><div class="gmail_extra"><br></div><div class="gmail_extra">Well, if someone does some test on TestPyPI and later abandons it, we don't need to have as many qualms about removing the project than we do with a project on PyPI proper.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">We could even have an official grace period, like a few months, before we consider that a project on TestPyPI without a PyPI equivalent can be considered abandoned.</div><div class="gmail_extra"><br></div></div><div class="gmail_extra">And if we do implement a minimum period on TestPyPI before graduation to PyPI, this would also give us a measure of protection from malicious typo squatting:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="http://incolumitas.com/2016/06/08/typosquatting-package-managers/">http://incolumitas.com/2016/06/08/typosquatting-package-managers/</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards,<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Leo</div><div class="gmail_extra"><br></div><div class="gmail_extra">On 22 July 2016 at 13:39, Donald Stufft <span dir="ltr"><<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="im"><br>
> On Jul 22, 2016, at 11:47 AM, Chris Barker - NOAA Federal <<a href="mailto:chris.barker@noaa.gov">chris.barker@noaa.gov</a>> wrote:<br>
><br>
><br>
</span><span class="im">> If the core devs think it's fine and dandy like it is, we can all stop<br>
> talking about it.<br>
<br>
</span><span class="im">I think they’re certainly a problem. The current solutions that have been<br>
proposed have their own problems of course, and problems enough that I<br>
don’t feel comfortable implementing them. Personally I don’t currently have<br>
the time to work on a better solution but if someone did that’d be fine<br>
with me.<br>
<br>
I would mention though that it’s possible there *is* no solution to this<br>
problem that doesn’t bring with it it’s own problems that are worse then<br>
the problem at hand. I’m not saying that’s the case, but just mentioning<br>
that it may be so.<br>
<br>
><br>
</span><span class="im">> By the way, there is an experiment underway with a "curated" community<br>
> package repository for conda packages:<br>
><br>
> <a href="https://conda-forge.github.io" rel="noreferrer" target="_blank">https://conda-forge.github.io</a><br>
><br>
> It's semi-curated, in the sense that only the core devs can approve a<br>
> package being added, but once added, anyone can maintain it.<br>
><br>
> It's going very well, but I'm not sure how it's going to scale. So<br>
> far, 900 or so packages, 80 or so maintainers. Which I think is very<br>
> impressive for a young system, but still a lot smaller than it could<br>
> be.<br>
><br>
> But I think PyPA should keep an eye on it -- I'm sure there will be<br>
> lessons learned.<br>
<br>
</span><span class="im">conda-forge and PyPI are not really similar. For conda-forge they’re largely<br>
just repackaging other software for the conda system. This makes it function<br>
better when you have just anyone of the core team able to work on stuff,<br>
because all they’re doing to adjusting the build, upgrading versions etc.<br>
They’re not working on the projects themselves.<br>
<br>
Curated also goes against the sort of “spirit” of PyPI. It’s a place where anyone<br>
can release something and immediately be able to be part of the ecosystem. Adding<br>
curation on top of that would change the nature of PyPI, maybe for the better or<br>
maybe for the worst, but it would fundamentally change PyPI.<br>
<br>
—<br>
Donald Stufft<br>
<br>
<br>
<br>
</span><div class=""><div class="h5">_______________________________________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</div></div></blockquote></div><br></div></div>