A process for removal of PyPi entries
Hello, is there a defined process for removing useless entries from PyPi? I was looking for a name for a new project, and as a part of that, I searched on the Python Package Index to see if the names I came up with are not taken already. I stumbled upon this: https://pypi.python.org/pypi/fun/1.0.0 Please note that there is absolutely no information about this entry. There is no way to contact the author and ask him if he would be willing to give up that name, no website, not even a license or description. If you look into the uploaded source code, you will see that it's just a "hello world" program. That's not a problem for me, I just picked a different name for my package. Even if I wanted to use that name, I could add a prefix or suffix to it, to make it unique. But then I looked through the list of the entires and checked the ones that had no description or their description was suspicious. Just with the letter A I got: https://pypi.python.org/pypi/42/0 https://pypi.python.org/pypi/Aaronyoungnester/1.4.0 https://pypi.python.org/pypi/ABC/0.0.0 https://pypi.python.org/pypi/abhi/2.0.0 https://pypi.python.org/pypi/acme.sql/0.0.0 https://pypi.python.org/pypi/affix/1.0 https://pypi.python.org/pypi/agg2567/1.1.0 https://pypi.python.org/pypi/agg2567/1.1.0 https://pypi.python.org/pypi/airstream/0 https://pypi.python.org/pypi/ajl_nester/1.1.0 https://pypi.python.org/pypi/akali/1.3.0 https://pypi.python.org/pypi/alexis/0.1 https://pypi.python.org/pypi/amoi/.lol. https://pypi.python.org/pypi/aodag3/1.0.0 https://pypi.python.org/pypi/arch/0.0.1 https://pypi.python.org/pypi/arounded/0.0 https://pypi.python.org/pypi/AthleteClass/1.0.0 https://pypi.python.org/pypi/athletelist/1.1.0 https://pypi.python.org/pypi/athletelist_jw/1.0.0 https://pypi.python.org/pypi/athletelistlogan/1.3.0 https://pypi.python.org/pypi/atool/1.0.0 https://pypi.python.org/pypi/awesomeness/0.0.1 https://pypi.python.org/pypi/aws-cli/0.0 https://pypi.python.org/pypi/ayame/0.0 All of those entries share some properties: * no author and no way to contact the author * no website, website offline or obviously not related (like google.com) * no description or meaningless description * no download url or uploaded code, or the code that is uploaded is just a "hello world" or similar exercise * no license I think that all those properties, taken together, in practice mean that the particular entry is completely useless both to the Python community and to its author -- possibly being just an abandoned test. I also think that there should be a defined process for requesting of removal of such entries -- so that an actually useful project can take their place. I understand that some of those entries are placeholders for projects that are actively being worked upon, just not much is disclosed yet. In that case, they could at least have an author contact information, a link to the repository or an "development status: in planning" trove classifier. Those project would be left alone. An additional check that could be done on the PyPi side is whether the same PuPi user has also some other entries that are perhaps more meaningful and contain contact information. They could be then contacted and asked about the status of their abandoned entries. If such a process existed and was publicly announced in the PyPi documentation, then there would be less work with this kind of maintenance, and no animosity in case of a needed entry being removed -- people would know what to expect. Thank you for all the good work on PyPi, -- Radomir Dopieralski, http://sheep.art.pl
I support this message. On Fri, May 31, 2013 at 12:57 PM, Radomir Dopieralski <sheep@sheep.art.pl> wrote:
Hello,
is there a defined process for removing useless entries from PyPi?
I was looking for a name for a new project, and as a part of that, I searched on the Python Package Index to see if the names I came up with are not taken already. I stumbled upon this:
https://pypi.python.org/pypi/fun/1.0.0
Please note that there is absolutely no information about this entry. There is no way to contact the author and ask him if he would be willing to give up that name, no website, not even a license or description. If you look into the uploaded source code, you will see that it's just a "hello world" program.
That's not a problem for me, I just picked a different name for my package. Even if I wanted to use that name, I could add a prefix or suffix to it, to make it unique. But then I looked through the list of the entires and checked the ones that had no description or their description was suspicious. Just with the letter A I got:
https://pypi.python.org/pypi/42/0 https://pypi.python.org/pypi/Aaronyoungnester/1.4.0 https://pypi.python.org/pypi/ABC/0.0.0 https://pypi.python.org/pypi/abhi/2.0.0 https://pypi.python.org/pypi/acme.sql/0.0.0 https://pypi.python.org/pypi/affix/1.0 https://pypi.python.org/pypi/agg2567/1.1.0 https://pypi.python.org/pypi/agg2567/1.1.0 https://pypi.python.org/pypi/airstream/0 https://pypi.python.org/pypi/ajl_nester/1.1.0 https://pypi.python.org/pypi/akali/1.3.0 https://pypi.python.org/pypi/alexis/0.1 https://pypi.python.org/pypi/amoi/.lol. https://pypi.python.org/pypi/aodag3/1.0.0 https://pypi.python.org/pypi/arch/0.0.1 https://pypi.python.org/pypi/arounded/0.0 https://pypi.python.org/pypi/AthleteClass/1.0.0 https://pypi.python.org/pypi/athletelist/1.1.0 https://pypi.python.org/pypi/athletelist_jw/1.0.0 https://pypi.python.org/pypi/athletelistlogan/1.3.0 https://pypi.python.org/pypi/atool/1.0.0 https://pypi.python.org/pypi/awesomeness/0.0.1 https://pypi.python.org/pypi/aws-cli/0.0 https://pypi.python.org/pypi/ayame/0.0
All of those entries share some properties:
* no author and no way to contact the author * no website, website offline or obviously not related (like google.com) * no description or meaningless description * no download url or uploaded code, or the code that is uploaded is just a "hello world" or similar exercise * no license
I think that all those properties, taken together, in practice mean that the particular entry is completely useless both to the Python community and to its author -- possibly being just an abandoned test. I also think that there should be a defined process for requesting of removal of such entries -- so that an actually useful project can take their place.
I understand that some of those entries are placeholders for projects that are actively being worked upon, just not much is disclosed yet. In that case, they could at least have an author contact information, a link to the repository or an "development status: in planning" trove classifier. Those project would be left alone.
An additional check that could be done on the PyPi side is whether the same PuPi user has also some other entries that are perhaps more meaningful and contain contact information. They could be then contacted and asked about the status of their abandoned entries.
If such a process existed and was publicly announced in the PyPi documentation, then there would be less work with this kind of maintenance, and no animosity in case of a needed entry being removed -- people would know what to expect.
Thank you for all the good work on PyPi,
-- Radomir Dopieralski, http://sheep.art.pl _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
On 31 maj 2013, at 12:57, Radomir Dopieralski <sheep@sheep.art.pl> wrote:
I was looking for a name for a new project, and as a part of that, I searched on the Python Package Index to see if the names I came up with are not taken already.
I concur. It's increasingly easy to find bogus entries on the index. We've had this quite recently with Hynek trying to publish "first" and finding out there's a package of that name. Fortunately we were able to work it out with Richard but we had to contact him directly and waste his cycles on this. Same thing happened with "proxy" but in this case Richard decided that while the currect package is bogus, the name is bad anyway and he's not freeing it up ;) Which is fair enough, but again - wasted cycles and no clear process.
All of those entries share some properties:
* no author and no way to contact the author * no website, website offline or obviously not related (like google.com) * no description or meaningless description * no download url or uploaded code, or the code that is uploaded is just a "hello world" or similar exercise * no license
The simplest approach would be to expire unused package names after, say, 6 months. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev
Hi Radomir, On Fri, May 31, 2013 at 12:57 +0200, Radomir Dopieralski wrote:
Hello,
is there a defined process for removing useless entries from PyPi?
I was looking for a name for a new project, and as a part of that, I searched on the Python Package Index to see if the names I came up with are not taken already. I stumbled upon this:
https://pypi.python.org/pypi/fun/1.0.0
Please note that there is absolutely no information about this entry. There is no way to contact the author and ask him if he would be willing to give up that name, no website, not even a license or description. If you look into the uploaded source code, you will see that it's just a "hello world" program.
That's not a problem for me, I just picked a different name for my package. Even if I wanted to use that name, I could add a prefix or suffix to it, to make it unique. But then I looked through the list of the entires and checked the ones that had no description or their description was suspicious. Just with the letter A I got:
https://pypi.python.org/pypi/42/0 https://pypi.python.org/pypi/Aaronyoungnester/1.4.0 https://pypi.python.org/pypi/ABC/0.0.0 https://pypi.python.org/pypi/abhi/2.0.0 https://pypi.python.org/pypi/acme.sql/0.0.0 https://pypi.python.org/pypi/affix/1.0 https://pypi.python.org/pypi/agg2567/1.1.0 https://pypi.python.org/pypi/agg2567/1.1.0 https://pypi.python.org/pypi/airstream/0 https://pypi.python.org/pypi/ajl_nester/1.1.0 https://pypi.python.org/pypi/akali/1.3.0 https://pypi.python.org/pypi/alexis/0.1 https://pypi.python.org/pypi/amoi/.lol. https://pypi.python.org/pypi/aodag3/1.0.0 https://pypi.python.org/pypi/arch/0.0.1 https://pypi.python.org/pypi/arounded/0.0 https://pypi.python.org/pypi/AthleteClass/1.0.0 https://pypi.python.org/pypi/athletelist/1.1.0 https://pypi.python.org/pypi/athletelist_jw/1.0.0 https://pypi.python.org/pypi/athletelistlogan/1.3.0 https://pypi.python.org/pypi/atool/1.0.0 https://pypi.python.org/pypi/awesomeness/0.0.1 https://pypi.python.org/pypi/aws-cli/0.0 https://pypi.python.org/pypi/ayame/0.0
All of those entries share some properties:
* no author and no way to contact the author * no website, website offline or obviously not related (like google.com) * no description or meaningless description * no download url or uploaded code, or the code that is uploaded is just a "hello world" or similar exercise * no license
I think that all those properties, taken together, in practice mean that the particular entry is completely useless both to the Python community and to its author -- possibly being just an abandoned test. I also think that there should be a defined process for requesting of removal of such entries -- so that an actually useful project can take their place.
I understand that some of those entries are placeholders for projects that are actively being worked upon, just not much is disclosed yet. In that case, they could at least have an author contact information, a link to the repository or an "development status: in planning" trove classifier. Those project would be left alone.
An additional check that could be done on the PyPi side is whether the same PuPi user has also some other entries that are perhaps more meaningful and contain contact information. They could be then contacted and asked about the status of their abandoned entries.
If such a process existed and was publicly announced in the PyPi documentation, then there would be less work with this kind of maintenance, and no animosity in case of a needed entry being removed -- people would know what to expect.
I think there should be a PEP regulating the removal and the "taking over" process for packages. Your considerations make sense to me there. ASFAIK Perl has such policies a decade or so. Probably makes sense to use their provisions as a blue print. Such a PEP should contain a list of projects that are to be removed retro-actively if they don't comply within 6 months or so. I think the barrier shouldn't be too high, a valid email address and/or release activity are a good minimum. And it should be a short PEP :) cheers, holger
Thank you for all the good work on PyPi,
-- Radomir Dopieralski, http://sheep.art.pl _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
On Fri, May 31, 2013 at 3:09 PM, holger krekel <holger@merlinux.eu> wrote:
I think there should be a PEP regulating the removal and the "taking over" process for packages. Your considerations make sense to me there. ASFAIK Perl has such policies a decade or so. Probably makes sense to use their provisions as a blue print. Such a PEP should contain a list of projects that are to be removed retro-actively if they don't comply within 6 months or so. I think the barrier shouldn't be too high, a valid email address and/or release activity are a good minimum. And it should be a short PEP :)
I'd be OK with after six months automatically removing packages that has only one owner/maintainer, and that owner/maintainer has no other packages, and the package has no available downloads, and no contact information on either package nor registered user. For other cases there should also be a manual way or removing packages on the discretion of PyPI maintainers, as well as giving owner access to packages whose owner is unreachable (I think there may already exist a process for that). //Lennart
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/31/2013 09:18 AM, Lennart Regebro wrote:
I'd be OK with after six months automatically removing packages that has only one owner/maintainer, and that owner/maintainer has no other packages, and the package has no available downloads, and no contact information on either package nor registered user.
Why all the extras: if somebody wants to claim a project name, but can't upload a release for six months, they should just lose. I would actually be willing to have that cut down to a day: trying to grab the name before registering / uploading a release should result in loss of the claim. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGpCWIACgkQ+gerLs4ltQ6e5wCbBm6t1T8a5ffPGBEFV0K3s3Fg jA8AoLVfTLCrSy6aCAbogcEouQc8H8Ak =bZTd -----END PGP SIGNATURE-----
On May 31, 2013, at 1:34 PM, Tres Seaver wrote:
On 05/31/2013 09:18 AM, Lennart Regebro wrote:
I'd be OK with after six months automatically removing packages that has only one owner/maintainer, and that owner/maintainer has no other packages, and the package has no available downloads, and no contact information on either package nor registered user.
Why all the extras: if somebody wants to claim a project name, but can't upload a release for six months, they should just lose. I would actually be willing to have that cut down to a day: trying to grab the name before registering / uploading a release should result in loss of the claim.
+1, I think this should just be treated as a form validation thing. It is a detail of the protocol that you upload a dist definition before the files, but I don't think we should consider it a valid PyPI entry until a file is uploaded (especially now that the default mode is to not scrape external sites). As we switch to not scraping, anything with no files should just vanish IMO, at which point it is available for registration again. If someone happens to ninja-upload between the setup.py register and setup.py upload, I think we can just throw an error message since chances of that happening are so amazingly low. --Noah
On May 31, 2013, at 4:45 PM, Noah Kantrowitz <noah@coderanger.net> wrote:
On May 31, 2013, at 1:34 PM, Tres Seaver wrote:
On 05/31/2013 09:18 AM, Lennart Regebro wrote:
I'd be OK with after six months automatically removing packages that has only one owner/maintainer, and that owner/maintainer has no other packages, and the package has no available downloads, and no contact information on either package nor registered user.
Why all the extras: if somebody wants to claim a project name, but can't upload a release for six months, they should just lose. I would actually be willing to have that cut down to a day: trying to grab the name before registering / uploading a release should result in loss of the claim.
+1, I think this should just be treated as a form validation thing. It is a detail of the protocol that you upload a dist definition before the files, but I don't think we should consider it a valid PyPI entry until a file is uploaded (especially now that the default mode is to not scrape external sites). As we switch to not scraping, anything with no files should just vanish IMO, at which point it is available for registration again. If someone happens to ninja-upload between the setup.py register and setup.py upload, I think we can just throw an error message since chances of that happening are so amazingly low.
--Noah
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
So I completely agree with the sentiment. However we need to make sure whatever process we come up with has provisions for when it's ok to manually remove a name as well. The reasoning is that it can easily become an arms race of sort. If we say "well projects without a file get auto deleted after a day", then someone wanting to squat a name will just upload a dummy file. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 31/05/2013 21:45, Noah Kantrowitz wrote:
On May 31, 2013, at 1:34 PM, Tres Seaver wrote:
On 05/31/2013 09:18 AM, Lennart Regebro wrote:
I'd be OK with after six months automatically removing packages that has only one owner/maintainer, and that owner/maintainer has no other packages, and the package has no available downloads, and no contact information on either package nor registered user.
Why all the extras: if somebody wants to claim a project name, but can't upload a release for six months, they should just lose. I would actually be willing to have that cut down to a day: trying to grab the name before registering / uploading a release should result in loss of the claim.
+1, I think this should just be treated as a form validation thing. It is a detail of the protocol that you upload a dist definition before the files, but I don't think we should consider it a valid PyPI entry until a file is uploaded (especially now that the default mode is to not scrape external sites). As we switch to not scraping, anything with no files should just vanish IMO, at which point it is available for registration again. If someone happens to ninja-upload between the setup.py register and setup.py upload, I think we can just throw an error message since chances of that happening are so amazingly low.
I'm afraid I need to -1 on this. If I'm developing a new package, I try and avoid putting a release on PyPI until I have something stable, but I'll often put up an entry on PyPI explaining where the code is being developed. Working on a project for a year only to find that someone else has stolen your package name on PyPI (playing devils advocate here, lets say they saw the development of GitHub and knew a release was brewing, etc) and having to go through and rename everything seems unfairly painful... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On 1 June 2013 16:00, Chris Withers <chris@simplistix.co.uk> wrote:
I'm afraid I need to -1 on this. If I'm developing a new package, I try and avoid putting a release on PyPI until I have something stable, but I'll often put up an entry on PyPI explaining where the code is being developed.
Working on a project for a year only to find that someone else has stolen your package name on PyPI (playing devils advocate here, lets say they saw the development of GitHub and knew a release was brewing, etc) and having to go through and rename everything seems unfairly painful...
I'd say that at a minimum, no deletion should happen without the author being contacted. As long as there's an author email, and the author actually replies to emails saying "do you mind if I take over this project name". I'm -1 on anything that doesn't involve at least a minimal level of human involvement (possibly excepting an initial clean up exercise for projects with no author email) Paul
On Sat, Jun 1, 2013 at 9:20 PM, Paul Moore <p.f.moore@gmail.com> wrote:
I'm -1 on anything that doesn't involve at least a minimal level of human involvement (possibly excepting an initial clean up exercise for projects with no author email)
This is why I basically said I'm OK with automatic deletion after a time if there are no downloadable packages and no contact information. Otherwise the owner should be contacted.
On Sat, Jun 1, 2013 at 4:29 PM, Lennart Regebro <regebro@gmail.com> wrote:
On Sat, Jun 1, 2013 at 9:20 PM, Paul Moore <p.f.moore@gmail.com> wrote:
I'm -1 on anything that doesn't involve at least a minimal level of human involvement (possibly excepting an initial clean up exercise for projects with no author email)
This is why I basically said I'm OK with automatic deletion after a time if there are no downloadable packages and no contact information. Otherwise the owner should be contacted.
Some people are saying "files uploaded" vs. "downloadable packages". I don't like the "files uploaded" criterion because IMO it's a perfectly valid use case to list a package on PyPI which is only available via external revision control. Heck, a project that only has planning documents and a reasonably active mailing list should still qualify for PyPI listing, else the original distutils-sig would not have qualified for reserving the name "distutils" on PyPI, before its first release. ;-)
On Jun 2, 2013, at 7:21 PM, PJ Eby wrote:
On Sat, Jun 1, 2013 at 4:29 PM, Lennart Regebro <regebro@gmail.com> wrote:
On Sat, Jun 1, 2013 at 9:20 PM, Paul Moore <p.f.moore@gmail.com> wrote:
I'm -1 on anything that doesn't involve at least a minimal level of human involvement (possibly excepting an initial clean up exercise for projects with no author email)
This is why I basically said I'm OK with automatic deletion after a time if there are no downloadable packages and no contact information. Otherwise the owner should be contacted.
Some people are saying "files uploaded" vs. "downloadable packages". I don't like the "files uploaded" criterion because IMO it's a perfectly valid use case to list a package on PyPI which is only available via external revision control.
Sorry, if you haven't had time to follow lately we have already begun deprecating this system. It is entirely reasonable to start making plans for the case when this will no longer be an option.
Heck, a project that only has planning documents and a reasonably active mailing list should still qualify for PyPI listing, else the original distutils-sig would not have qualified for reserving the name "distutils" on PyPI, before its first release. ;-)
If a reasonably active project doesn't have anything to show after six months, I think we have different definitions of 'reasonably active'. --Noah
On 03/06/2013 03:43, Noah Kantrowitz wrote:
Some people are saying "files uploaded" vs. "downloadable packages". I don't like the "files uploaded" criterion because IMO it's a perfectly valid use case to list a package on PyPI which is only available via external revision control.
Sorry, if you haven't had time to follow lately we have already begun deprecating this system.
I hope you're misunderstanding what pje is saying; this isn't about hosting distributions elsewhere, this is about having a PyPI listing for a project that is under development but it hasn't got to the point where it's sensible for a release to be made.
Heck, a project that only has planning documents and a reasonably active mailing list should still qualify for PyPI listing, else the original distutils-sig would not have qualified for reserving the name "distutils" on PyPI, before its first release. ;-)
If a reasonably active project doesn't have anything to show after six months, I think we have different definitions of 'reasonably active'.
...or different definitions of 'software quality' ;-) Seriously, I don't think anyone would argue that we have enough nested list printers in this world or that a package without any contact details or description is fair game to delete, but I must echo what others have said in that a unilateral process where a project is deleted without the owner being given a reasonable time to respond doesn't seem like a good idea. cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On Jun 3, 2013, at 2:22 AM, Chris Withers <chris@simplistix.co.uk> wrote:
On 03/06/2013 03:43, Noah Kantrowitz wrote:
Some people are saying "files uploaded" vs. "downloadable packages". I don't like the "files uploaded" criterion because IMO it's a perfectly valid use case to list a package on PyPI which is only available via external revision control.
Sorry, if you haven't had time to follow lately we have already begun deprecating this system.
I hope you're misunderstanding what pje is saying; this isn't about hosting distributions elsewhere, this is about having a PyPI listing for a project that is under development but it hasn't got to the point where it's sensible for a release to be made.
Heck, a project that only has planning documents and a reasonably active mailing list should still qualify for PyPI listing, else the original distutils-sig would not have qualified for reserving the name "distutils" on PyPI, before its first release. ;-)
If a reasonably active project doesn't have anything to show after six months, I think we have different definitions of 'reasonably active'.
...or different definitions of 'software quality' ;-)
Seriously, I don't think anyone would argue that we have enough nested list printers in this world or that a package without any contact details or description is fair game to delete, but I must echo what others have said in that a unilateral process where a project is deleted without the owner being given a reasonable time to respond doesn't seem like a good idea.
Unless I missed it I don't think I've seen *anyone* suggest that projects where the authors appear to actually have plans to use the name have the name yanked out from underneath them.
cheers,
Chris
-- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 03/06/2013 08:13, Donald Stufft wrote:
If a reasonably active project doesn't have anything to show after six months, I think we have different definitions of 'reasonably active'.
...or different definitions of 'software quality' ;-)
Seriously, I don't think anyone would argue that we have enough nested list printers in this world or that a package without any contact details or description is fair game to delete, but I must echo what others have said in that a unilateral process where a project is deleted without the owner being given a reasonable time to respond doesn't seem like a good idea.
Unless I missed it I don't think I've seen *anyone* suggest that projects where the authors appear to actually have plans to use the name have the name yanked out from underneath them.
...in that case, I'm happy to find out I have misunderstood :-) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On Mon, Jun 3, 2013 at 4:21 AM, PJ Eby <pje@telecommunity.com> wrote:
On Sat, Jun 1, 2013 at 4:29 PM, Lennart Regebro <regebro@gmail.com> wrote:
On Sat, Jun 1, 2013 at 9:20 PM, Paul Moore <p.f.moore@gmail.com> wrote:
I'm -1 on anything that doesn't involve at least a minimal level of human involvement (possibly excepting an initial clean up exercise for projects with no author email)
This is why I basically said I'm OK with automatic deletion after a time if there are no downloadable packages and no contact information. Otherwise the owner should be contacted.
Some people are saying "files uploaded" vs. "downloadable packages". I don't like the "files uploaded" criterion because IMO it's a perfectly valid use case to list a package on PyPI which is only available via external revision control.
Heck, a project that only has planning documents and a reasonably active mailing list should still qualify for PyPI listing, else the original distutils-sig would not have qualified for reserving the name "distutils" on PyPI, before its first release. ;-)
Absolutely. Which gets us back to the "nothing to download, no way of contacting" criteria I originally proposed. :-) //Lennart
On 03/06/2013 06:56, Lennart Regebro wrote:
On Mon, Jun 3, 2013 at 4:21 AM, PJ Eby<pje@telecommunity.com> wrote:
On Sat, Jun 1, 2013 at 4:29 PM, Lennart Regebro<regebro@gmail.com> wrote:
On Sat, Jun 1, 2013 at 9:20 PM, Paul Moore<p.f.moore@gmail.com> wrote:
I'm -1 on anything that doesn't involve at least a minimal level of human involvement (possibly excepting an initial clean up exercise for projects with no author email)
This is why I basically said I'm OK with automatic deletion after a time if there are no downloadable packages and no contact information. Otherwise the owner should be contacted.
Some people are saying "files uploaded" vs. "downloadable packages". I don't like the "files uploaded" criterion because IMO it's a perfectly valid use case to list a package on PyPI which is only available via external revision control.
Heck, a project that only has planning documents and a reasonably active mailing list should still qualify for PyPI listing, else the original distutils-sig would not have qualified for reserving the name "distutils" on PyPI, before its first release. ;-)
Absolutely. Which gets us back to the "nothing to download, no way of contacting" criteria I originally proposed. :-)
+1 :-) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
Quoting Paul Moore <p.f.moore@gmail.com>:
I'm -1 on anything that doesn't involve at least a minimal level of human involvement (possibly excepting an initial clean up exercise for projects with no author email)
I support this position. This is actually how PyPI has operated over the last decade. People have always taken over projects, either the project entirely, or just the name. It always involved contacting the original owner of the name. In this thread, Lukas wrote
Fortunately we were able to work it out with Richard but we had to contact him directly and waste his cycles on this.
I don't consider his cycles wasted at all. It's an important interaction. I'm fine with formalizing the process, and I'm also fine with adding tool support. However, I agree that a PEP should be written and agreed about this. Personally, I'd favor this procedure: - nothing happens unless some user explicitly requests it - on request, the owner is contacted, and given some time to respond - if they do respond, and are unwilling to yield the name, nothing happens - if they have confirmed that they want to keep the name, they won't be asked again for at least one year. Regards, Martin
On Jun 2, 2013, at 6:51 AM, martin@v.loewis.de wrote:
Quoting Paul Moore <p.f.moore@gmail.com>:
I'm -1 on anything that doesn't involve at least a minimal level of human involvement (possibly excepting an initial clean up exercise for projects with no author email)
I support this position. This is actually how PyPI has operated over the last decade. People have always taken over projects, either the project entirely, or just the name. It always involved contacting the original owner of the name.
In this thread, Lukas wrote
Fortunately we were able to work it out with Richard but we had to contact him directly and waste his cycles on this.
I don't consider his cycles wasted at all. It's an important interaction.
I'm fine with formalizing the process, and I'm also fine with adding tool support. However, I agree that a PEP should be written and agreed about this.
Personally, I'd favor this procedure: - nothing happens unless some user explicitly requests it - on request, the owner is contacted, and given some time to respond - if they do respond, and are unwilling to yield the name, nothing happens - if they have confirmed that they want to keep the name, they won't be asked again for at least one year.
The missing case here is what happens if they don't respond?
Regards, Martin
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 2 June 2013 12:54, Donald Stufft <donald@stufft.io> wrote:
The missing case here is what happens if they don't respond?
That (and when there is no author contact details) is when a unilateral process *is* needed. In those cases, I'd argue that we should have some overall guidelines to work from, but ultimately the PyPI admin(s) should decide on a case by case basis. If and when the volume of such requests gets so great that the admins are overwhelmed, *then* we should look at the feasibility of an automatic process. Paul
I also support human involvement. I don't deal with so many cases that it's such a burden - though I do have a bit of a backlog at the moment due to lack of personal time. Having said that, I can see value in automatically clearing out empty (no meta-data, no files) registrations 6+ months after they're created. On 2 June 2013 20:51, <martin@v.loewis.de> wrote:
Quoting Paul Moore <p.f.moore@gmail.com>:
I'm -1 on anything that doesn't involve at least a minimal level of human
involvement (possibly excepting an initial clean up exercise for projects with no author email)
I support this position. This is actually how PyPI has operated over the last decade. People have always taken over projects, either the project entirely, or just the name. It always involved contacting the original owner of the name.
In this thread, Lukas wrote
Fortunately we were able to work it out with Richard
but we had to contact him directly and waste his cycles on this.
I don't consider his cycles wasted at all. It's an important interaction.
I'm fine with formalizing the process, and I'm also fine with adding tool support. However, I agree that a PEP should be written and agreed about this.
Personally, I'd favor this procedure: - nothing happens unless some user explicitly requests it - on request, the owner is contacted, and given some time to respond - if they do respond, and are unwilling to yield the name, nothing happens - if they have confirmed that they want to keep the name, they won't be asked again for at least one year.
Regards, Martin
______________________________**_________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/**mailman/listinfo/distutils-sig<http://mail.python.org/mailman/listinfo/distutils-sig>
On Fri 31 May 2013 04:34:43 PM EDT, Tres Seaver wrote:
Why all the extras: if somebody wants to claim a project name, but can't upload a release for six months, they should just lose. I would actually be willing to have that cut down to a day: trying to grab the name before registering / uploading a release should result in loss of the claim.
Firstly, let me say that the general idea sounds good, and should serve to improve PyPI security. However, it needs to be done carefully. Certainly Holger's idea of looking at how other programming language communities have done it is a good one. A potential problem with the "no new package in six months" heuristic is that it would punish mature packages with little or no improvements left. Would one defeat this rule by simply uploading a "new" package every six months? I am aware that packages have to change from time to time, if at least to keep up with language or other dependency changes, but the rules for weeding packages should be carefully thought out.
On Fri, May 31, 2013 at 4:45 PM, Trishank Karthik Kuppusamy <tk47@students.poly.edu> wrote:
On Fri 31 May 2013 04:34:43 PM EDT, Tres Seaver wrote:
Why all the extras: if somebody wants to claim a project name, but can't upload a release for six months, they should just lose. I would actually be willing to have that cut down to a day: trying to grab the name before registering / uploading a release should result in loss of the claim.
Firstly, let me say that the general idea sounds good, and should serve to improve PyPI security. However, it needs to be done carefully. Certainly Holger's idea of looking at how other programming language communities have done it is a good one.
A potential problem with the "no new package in six months" heuristic is that it would punish mature packages with little or no improvements left. Would one defeat this rule by simply uploading a "new" package every six months?
I think Tres was referring to the first release. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton
On Fri, May 31, 2013 at 6:33 PM, Trishank Karthik Kuppusamy <tk47@students.poly.edu> wrote:
On Fri 31 May 2013 06:16:28 PM EDT, Jim Fulton wrote:
I think Tres was referring to the first release.
Thanks for the clarification, but my argument remains for subsequent releases.
Hopefully, subsequent releases aren't an issue. IOW, I hope no one is proposing removing a project simply because someone hasn't released a new (after initial) release in some period of time. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/31/2013 06:41 PM, Jim Fulton wrote:
I hope no one is proposing removing a project simply because someone hasn't released a new (after initial) release in some period of time.
Certainly not I: I'd just like to prevent "squatters" (no matter how well-intentioned, Withers!) from tying up a project name indefinitely. Code talks, as it were: release something or take your marbles and go home. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGqky0ACgkQ+gerLs4ltQ74iwCgqSr4TqKC/ktgU0XlsDKedp2i 3ZwAnRnuuEX2imZlVs2CT54faUZFYo6l =qReS -----END PGP SIGNATURE-----
On Fri, May 31, 2013 at 10:34 PM, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/31/2013 09:18 AM, Lennart Regebro wrote:
I'd be OK with after six months automatically removing packages that has only one owner/maintainer, and that owner/maintainer has no other packages, and the package has no available downloads, and no contact information on either package nor registered user.
Why all the extras: if somebody wants to claim a project name, but can't upload a release for six months, they should just lose. I would actually be willing to have that cut down to a day: trying to grab the name before registering / uploading a release should result in loss of the claim.
Because it's automatic. I don't trust computers. ;-) But yeah, it could be shorter. //Lennart
Tres Seaver <tseaver <at> palladion.com> writes:
Why all the extras: if somebody wants to claim a project name, but can't upload a release for six months, they should just lose. I would actually be willing to have that cut down to a day: trying to grab the name before registering / uploading a release should result in loss of the claim.
Six months does seem somewhat long, but I think a day is draconian. For example, I registered the PyPI name for "distil" when I first thought of the name (part way through developing it, but some weeks before the first release). The first release makes first impressions, so it makes sense to take care over it, and that takes time - sometimes, more than a few days. While I don't think people should be able to claim and park project names indefinitely, the choice of a project name is not totally trivial, and if a developer picks a name they like for one of their projects and it's available, I don't believe they should be forced to upload their first release too soon. This doesn't seem like an issue which requires precipitate measures. (I do agree with the general sentiments of tightening up on project names, and having a process to harvest claimed but unused project names after a decent interval.) Regards, Vinay Sajip
On Fri, May 31, 2013 at 15:18 +0200, Lennart Regebro wrote:
On Fri, May 31, 2013 at 3:09 PM, holger krekel <holger@merlinux.eu> wrote:
I think there should be a PEP regulating the removal and the "taking over" process for packages. Your considerations make sense to me there. ASFAIK Perl has such policies a decade or so. Probably makes sense to use their provisions as a blue print. Such a PEP should contain a list of projects that are to be removed retro-actively if they don't comply within 6 months or so. I think the barrier shouldn't be too high, a valid email address and/or release activity are a good minimum. And it should be a short PEP :)
I'd be OK with after six months automatically removing packages that has only one owner/maintainer, and that owner/maintainer has no other packages, and the package has no available downloads, and no contact information on either package nor registered user.
For other cases there should also be a manual way or removing packages on the discretion of PyPI maintainers, as well as giving owner access to packages whose owner is unreachable (I think there may already exist a process for that).
I'd like to argue in the same direction. While technical means to detect unmaintained or empty registrations are worthwhile to consdier i believe we should put emphasize on the human process. If you look at perl's guidelines for taking over maintenance here: http://www.cpan.org/misc/cpan-faq.html#How_adopt_module it's focused on the human communication process which i think is the right way to go about it. Any technical automated solution can probably be abused easily, given ill intentions, see the DNS for reference. A PEP should list criteria but leave decisions ultimately to a trusted board/admins which should maintain a public changelog of their actions. Those criteria should of course be automatically analyzed and used as input for the human process if possible. best, holger
//Lennart
On May 31, 2013, at 6:57 AM, Radomir Dopieralski <sheep@sheep.art.pl> wrote:
Hello,
is there a defined process for removing useless entries from PyPi?
I was looking for a name for a new project, and as a part of that, I searched on the Python Package Index to see if the names I came up with are not taken already. I stumbled upon this:
https://pypi.python.org/pypi/fun/1.0.0
Please note that there is absolutely no information about this entry. There is no way to contact the author and ask him if he would be willing to give up that name, no website, not even a license or description. If you look into the uploaded source code, you will see that it's just a "hello world" program.
That's not a problem for me, I just picked a different name for my package. Even if I wanted to use that name, I could add a prefix or suffix to it, to make it unique. But then I looked through the list of the entires and checked the ones that had no description or their description was suspicious. Just with the letter A I got:
https://pypi.python.org/pypi/42/0 https://pypi.python.org/pypi/Aaronyoungnester/1.4.0 https://pypi.python.org/pypi/ABC/0.0.0 https://pypi.python.org/pypi/abhi/2.0.0 https://pypi.python.org/pypi/acme.sql/0.0.0 https://pypi.python.org/pypi/affix/1.0 https://pypi.python.org/pypi/agg2567/1.1.0 https://pypi.python.org/pypi/agg2567/1.1.0 https://pypi.python.org/pypi/airstream/0 https://pypi.python.org/pypi/ajl_nester/1.1.0 https://pypi.python.org/pypi/akali/1.3.0 https://pypi.python.org/pypi/alexis/0.1 https://pypi.python.org/pypi/amoi/.lol. https://pypi.python.org/pypi/aodag3/1.0.0 https://pypi.python.org/pypi/arch/0.0.1 https://pypi.python.org/pypi/arounded/0.0 https://pypi.python.org/pypi/AthleteClass/1.0.0 https://pypi.python.org/pypi/athletelist/1.1.0 https://pypi.python.org/pypi/athletelist_jw/1.0.0 https://pypi.python.org/pypi/athletelistlogan/1.3.0 https://pypi.python.org/pypi/atool/1.0.0 https://pypi.python.org/pypi/awesomeness/0.0.1 https://pypi.python.org/pypi/aws-cli/0.0 https://pypi.python.org/pypi/ayame/0.0
All of those entries share some properties:
* no author and no way to contact the author * no website, website offline or obviously not related (like google.com) * no description or meaningless description * no download url or uploaded code, or the code that is uploaded is just a "hello world" or similar exercise * no license
I think that all those properties, taken together, in practice mean that the particular entry is completely useless both to the Python community and to its author -- possibly being just an abandoned test. I also think that there should be a defined process for requesting of removal of such entries -- so that an actually useful project can take their place.
I understand that some of those entries are placeholders for projects that are actively being worked upon, just not much is disclosed yet. In that case, they could at least have an author contact information, a link to the repository or an "development status: in planning" trove classifier. Those project would be left alone.
An additional check that could be done on the PyPi side is whether the same PuPi user has also some other entries that are perhaps more meaningful and contain contact information. They could be then contacted and asked about the status of their abandoned entries.
If such a process existed and was publicly announced in the PyPi documentation, then there would be less work with this kind of maintenance, and no animosity in case of a needed entry being removed -- people would know what to expect.
Thank you for all the good work on PyPi,
-- Radomir Dopieralski, http://sheep.art.pl _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
There is no defined process. Getting one would be good. A PEP is likely warranted in order to define the process. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
participants (15)
-
Chris Withers -
Donald Stufft -
holger krekel -
Jim Fulton -
Lennart Regebro -
martin＠v.loewis.de -
Noah Kantrowitz -
Paul Moore -
PJ Eby -
Radomir Dopieralski -
Richard Jones -
Tres Seaver -
Trishank Karthik Kuppusamy -
Vinay Sajip -
Łukasz Langa