[Distutils] [issue149] 'pkg_resources' is not defined in ssl_support.py
New submission from Keith Yang:
File
/Users/keitheis/Quest/biienv/lib/python2.7/site-packages/setuptools/package_index.py,
line 161, in __init__
if verify_ssl and ssl_support.is_available and (ca_bundle or
ssl_support.find_ca_bundle()):
File
/Users/keitheis/Quest/biienv/lib/python2.7/site-packages/setuptools/ssl_support.py,
line 239, in find_ca_bundle
return pkg_resources.resource_filename('certifi', 'cacert.pem')
NameError: global name 'pkg_resources' is not defined
--
files: patch_ssl_support.diff
keyword: pkg_resources
messages: 717
nosy: keitheis
priority: bug
status: unread
title: 'pkg_resources' is not defined in ssl_support.py
Added file: http://bugs.python.org/setuptools/file89/patch_ssl_support.diff
___
Setuptools tracker setupto...@bugs.python.org
http://bugs.python.org/setuptools/issue149
___Index: setuptools/ssl_support.py
===
--- setuptools/ssl_support.py (revision 88997)
+++ setuptools/ssl_support.py (working copy)
@@ -236,7 +236,8 @@
if os.path.isfile(cert_path):
return cert_path
try:
-return pkg_resources.resource_filename('certifi', 'cacert.pem')
+from pkg_resources import resource_filename
+return resource_filename('certifi', 'cacert.pem')
except (ImportError, ResolutionError, ExtractionError):
return None
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] 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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
I support this message. On Fri, May 31, 2013 at 12:57 PM, Radomir Dopieralski sh...@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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
On 31 maj 2013, at 12:57, Radomir Dopieralski sh...@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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
On Fri, May 31, 2013 at 3:09 PM, holger krekel hol...@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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
On May 31, 2013, at 6:57 AM, Radomir Dopieralski sh...@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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] problems with sdist upload since CDN update
I'm also having trouble with uploading to pypi, it's not random,
meaning it's happened every time so far. My last upload was about a
week ago and seamless.
Here is my best reconstruction of today:
{{{
python setup.py sdist upload
...snip
adding 'leo-4.11.devel-build-5802\leo.egg-info\PKG-INFO'
adding 'leo-4.11.devel-build-5802\leo.egg-info\SOURCES.txt'
adding 'leo-4.11.devel-build-5802\leo.egg-info\top_level.txt'
removing 'leo-4.11.devel-build-5802' (and everything under it)
running upload
submitting d:/leo/dist\leo-4.11.devel-build-5802.zip to
http://pypi.python.org/pypi
upload failed (500): There's been a problem with your request
python setup.py sdist upload
:: same error
python setup.py register
:: was okay
python setup.py sdist upload
:: same error
}}}
I then went to https://pypi.python.org/pypi?%3Aaction=pkg_editname=leo
and noticed that I had my role mysteriously expanded to include Owner
as well as Maintainer.
I used the web interface and removed the Owner role for myself, and
then manually uploaded the sdist package, which succeeded.
Went back to cmd shell and:
{{{
B:\apps\leo\pypi-411python setup.py bdist_wininst upload
...snip
adding 'SCRIPTS\leoc-script.py'
adding 'SCRIPTS\leoc.exe'
adding 'SCRIPTS\leoc.exe.manifest'
removing 'd:/leo/build' (and everything under it)
running upload
Submitting d:/leo/dist\leo-4.11.devel-build-5802.win32.exe to
http://pypi.python.org/pypi
Server response (200): OK
Submitting d:/leo/dist\leo-4.11.devel-build-5802.win32.exe to
http://pypi.python.org/pypi
Upload failed (400): A file named
leo-4.11.devel-build-5802.win32.exe already exists for
leo-4.11.devel-build-5802. To fix problems with that file you should
create a new release.
}}}
Note the double upload.
Going back to the website https://pypi.python.org/pypi/leo there are
now 2 packages listed: leo 4.10-final, which corresponds to the
sdist package, and leo 4.11.devel-build-5802 corresponding the win32
.exe installer.
The metadata for 4.10-final has the correct author and maintainer, but
all the other metadata is old and hasn't been updated.
The metadata for 4.11-devel is up to date for homepage through
maintainer but has the wrong Author and is missing the long
description.
The journal entries for the 2 packages mirror each other except for
the last line:
{{{
Journal
Action DateUserAddress
create 2003-10-09 17:32edreamleo 66.168.19.217
add Owner edreamleo 2003-10-09 17:32edreamleo 66.168.19.217
new release 2012-03-29 13:53edreamleo 68.185.171.138
add Maintainer maphew 2013-05-07 13:08edreamleo 172.8.201.39
add Owner maphew2013-05-22 23:21maphew 199.247.128.35
update _pypi_hidden 2013-05-22 23:22maphew 199.247.128.35
update _pypi_hidden 2013-05-31 16:52maphew 199.27.75.22
remove Owner maphew 2013-05-31 16:53maphew 199.27.75.22
update hosting_mode 2013-05-31 16:56maphew 199.27.75.20
add source file leo-4.11.devel-build-5802.zip 2013-05-31 16:59
maphew 199.27.75.21
}}}
{{{
add any file leo-4.11.devel-build-5802.win32.exe2013-05-31 17:02
maphew 199.27.75.23
}}}
Also curious is that all the ip addresses for today are wrong and
variable. My external-to-world-ip should be 199.247.128.35 and static.
cheers,
-matt
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] problems with sdist upload since CDN update
On May 31, 2013, at 1:44 PM, Matt Wilkie map...@gmail.com wrote:
I'm also having trouble with uploading to pypi, it's not random,
meaning it's happened every time so far. My last upload was about a
week ago and seamless.
Here is my best reconstruction of today:
{{{
python setup.py sdist upload
...snip
adding 'leo-4.11.devel-build-5802\leo.egg-info\PKG-INFO'
adding 'leo-4.11.devel-build-5802\leo.egg-info\SOURCES.txt'
adding 'leo-4.11.devel-build-5802\leo.egg-info\top_level.txt'
removing 'leo-4.11.devel-build-5802' (and everything under it)
running upload
submitting d:/leo/dist\leo-4.11.devel-build-5802.zip to
http://pypi.python.org/pypi
upload failed (500): There's been a problem with your request
python setup.py sdist upload
:: same error
python setup.py register
:: was okay
python setup.py sdist upload
:: same error
}}}
I then went to https://pypi.python.org/pypi?%3Aaction=pkg_editname=leo
and noticed that I had my role mysteriously expanded to include Owner
as well as Maintainer.
I used the web interface and removed the Owner role for myself, and
then manually uploaded the sdist package, which succeeded.
Went back to cmd shell and:
{{{
B:\apps\leo\pypi-411python setup.py bdist_wininst upload
...snip
adding 'SCRIPTS\leoc-script.py'
adding 'SCRIPTS\leoc.exe'
adding 'SCRIPTS\leoc.exe.manifest'
removing 'd:/leo/build' (and everything under it)
running upload
Submitting d:/leo/dist\leo-4.11.devel-build-5802.win32.exe to
http://pypi.python.org/pypi
Server response (200): OK
Submitting d:/leo/dist\leo-4.11.devel-build-5802.win32.exe to
http://pypi.python.org/pypi
Upload failed (400): A file named
leo-4.11.devel-build-5802.win32.exe already exists for
leo-4.11.devel-build-5802. To fix problems with that file you should
create a new release.
}}}
Note the double upload.
Going back to the website https://pypi.python.org/pypi/leo there are
now 2 packages listed: leo 4.10-final, which corresponds to the
sdist package, and leo 4.11.devel-build-5802 corresponding the win32
.exe installer.
The metadata for 4.10-final has the correct author and maintainer, but
all the other metadata is old and hasn't been updated.
The metadata for 4.11-devel is up to date for homepage through
maintainer but has the wrong Author and is missing the long
description.
The journal entries for the 2 packages mirror each other except for
the last line:
{{{
Journal
ActionDateUserAddress
create2003-10-09 17:32edreamleo 66.168.19.217
add Owner edreamleo 2003-10-09 17:32edreamleo 66.168.19.217
new release 2012-03-29 13:53edreamleo 68.185.171.138
add Maintainer maphew 2013-05-07 13:08edreamleo
172.8.201.39
add Owner maphew 2013-05-22 23:21maphew 199.247.128.35
update _pypi_hidden 2013-05-22 23:22maphew 199.247.128.35
update _pypi_hidden 2013-05-31 16:52maphew 199.27.75.22
remove Owner maphew 2013-05-31 16:53maphew 199.27.75.22
update hosting_mode 2013-05-31 16:56maphew 199.27.75.20
add source file leo-4.11.devel-build-5802.zip 2013-05-31 16:59
maphew 199.27.75.21
}}}
{{{
add any file leo-4.11.devel-build-5802.win32.exe 2013-05-31 17:02
maphew 199.27.75.23
}}}
Also curious is that all the ip addresses for today are wrong and
variable. My external-to-world-ip should be 199.247.128.35 and static.
cheers,
-matt
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
I see an exception here in Sentry, I'll investigate further in a bit.
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] problems with sdist upload since CDN update
On May 31, 2013, at 2:10 PM, Donald Stufft don...@stufft.io wrote:
On May 31, 2013, at 1:44 PM, Matt Wilkie map...@gmail.com wrote:
I'm also having trouble with uploading to pypi, it's not random,
meaning it's happened every time so far. My last upload was about a
week ago and seamless.
Here is my best reconstruction of today:
{{{
python setup.py sdist upload
...snip
adding 'leo-4.11.devel-build-5802\leo.egg-info\PKG-INFO'
adding 'leo-4.11.devel-build-5802\leo.egg-info\SOURCES.txt'
adding 'leo-4.11.devel-build-5802\leo.egg-info\top_level.txt'
removing 'leo-4.11.devel-build-5802' (and everything under it)
running upload
submitting d:/leo/dist\leo-4.11.devel-build-5802.zip to
http://pypi.python.org/pypi
upload failed (500): There's been a problem with your request
python setup.py sdist upload
:: same error
python setup.py register
:: was okay
python setup.py sdist upload
:: same error
}}}
I then went to https://pypi.python.org/pypi?%3Aaction=pkg_editname=leo
and noticed that I had my role mysteriously expanded to include Owner
as well as Maintainer.
I used the web interface and removed the Owner role for myself, and
then manually uploaded the sdist package, which succeeded.
Went back to cmd shell and:
{{{
B:\apps\leo\pypi-411python setup.py bdist_wininst upload
...snip
adding 'SCRIPTS\leoc-script.py'
adding 'SCRIPTS\leoc.exe'
adding 'SCRIPTS\leoc.exe.manifest'
removing 'd:/leo/build' (and everything under it)
running upload
Submitting d:/leo/dist\leo-4.11.devel-build-5802.win32.exe to
http://pypi.python.org/pypi
Server response (200): OK
Submitting d:/leo/dist\leo-4.11.devel-build-5802.win32.exe to
http://pypi.python.org/pypi
Upload failed (400): A file named
leo-4.11.devel-build-5802.win32.exe already exists for
leo-4.11.devel-build-5802. To fix problems with that file you should
create a new release.
}}}
Note the double upload.
Going back to the website https://pypi.python.org/pypi/leo there are
now 2 packages listed: leo 4.10-final, which corresponds to the
sdist package, and leo 4.11.devel-build-5802 corresponding the win32
.exe installer.
The metadata for 4.10-final has the correct author and maintainer, but
all the other metadata is old and hasn't been updated.
The metadata for 4.11-devel is up to date for homepage through
maintainer but has the wrong Author and is missing the long
description.
The journal entries for the 2 packages mirror each other except for
the last line:
{{{
Journal
Action DateUserAddress
create 2003-10-09 17:32edreamleo 66.168.19.217
add Owner edreamleo 2003-10-09 17:32edreamleo 66.168.19.217
new release 2012-03-29 13:53edreamleo 68.185.171.138
add Maintainer maphew2013-05-07 13:08edreamleo
172.8.201.39
add Owner maphew 2013-05-22 23:21maphew 199.247.128.35
update _pypi_hidden 2013-05-22 23:22maphew 199.247.128.35
update _pypi_hidden 2013-05-31 16:52maphew 199.27.75.22
remove Owner maphew 2013-05-31 16:53maphew 199.27.75.22
update hosting_mode 2013-05-31 16:56maphew 199.27.75.20
add source file leo-4.11.devel-build-5802.zip2013-05-31 16:59
maphew 199.27.75.21
}}}
{{{
add any file leo-4.11.devel-build-5802.win32.exe 2013-05-31 17:02
maphew 199.27.75.23
}}}
Also curious is that all the ip addresses for today are wrong and
variable. My external-to-world-ip should be 199.247.128.35 and static.
cheers,
-matt
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
I see an exception here in Sentry, I'll investigate further in a bit.
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Matt, is your code available online anywhere?
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
-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 tsea...@palladion.com Palladion Software Excellence by Designhttp://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- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
On Fri, May 31, 2013 at 10:34 PM, Tres Seaver tsea...@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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
On May 31, 2013, at 4:45 PM, Noah Kantrowitz n...@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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
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. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Binary Wheels and universal builds on OS-X
HI Folks, A few of us over on the pythonmac list have been hashing out how best to support binary packages on OS-X. The binary wheel option seems very promising. However, there is one Mac-specific issue that does not seem to be addressed: On OS-X, binaries can be universal -- what this means is that they have more than one binary architecture embedded in a single file; the system selects the right one at run time. Both executables and dynamic libraries can be universal. In theory, an universal binary can currently contain up to 4 architectures: 32+64 bit PPC and 32+64bit x86 In practice, 64 bit PPC was never broadly used, and 32bit PPC is fading fast. Nevertheless, both 32 and 64 Intel systems are pretty common, and who knows what there may be in the future (you never know with Apple...) The binary builds of Python served up on the python.org web site have supported universal builds for years -- currently there are two options: 32bit PPC+x86 or 32+64bit x86. It's not a single build, as it turns out it's hard to support both up to date x86_64 and PPC with the same compiler. In these builds, the configuration is set up so that distutils will build universal extensions that match the architectures included in the builds. This makes it pretty easy to build binary packages, and/or full app distributions (py2app) that are universal as well. setuptools' easy_install supports binary eggs, but always choked on universal builds -- it didn't know how to identify what matched the system. It would be really nice if future tools could identify and install the correct binary wheels for universal builds. I've taken a look at PEP 427, and see this: platform tag E.g. 'linux_x86_64', 'any'. That looks to me like there is a built-in assumption that a wheel is either specific to a single architecture, or any -- so no way to specify that it may have multiple architectures. So I propose that platform tag allow a list of some sort: ['macosx-10_6_i386', 'macosx_10_6-x86_64'] or, I suppose to keep it simple, a single string: 'macosx_10_6_i386+macosx_10_6_x86_64' or 'macosx_10_6_i386+x86_64' If so, then a binary wheel could be built (and discovered) that supported multiple architectures. Then how would an installer ( pip? ) identify the right one? This is a bit tricky. PEP 425 states: The platform tag is simply distutils.util.get_platform() with all hyphens - and periods . replaced with underscore On my system right now, I have 32bitPPC + 32bit i386 universal python, running on an intel system: In [2]: distutils.util.get_platform() Out[2]: 'macosx-10.3-i386' So we may want to patch get_platform() to support universal builds - or add anther function or something -- you may sometimes what to know what you are running right now, and other times want to know how the current python is built. (note that while distutils can build universal binaries, it's not very smart about it -- all is does is grab the compiler and linker flags from the Makefile, which include multiple -arch flags. Even if there is an easy way to query the system, that leaves the question of what to do. If a user wants to intall a package into a universal python, will the installer only accept a binary wheel with all the supported architectures? or one with only the currently running one? Anyway, it would be nice to be able to get this stuff to just work with universal binaries on the Mac. Thoughts, ideas? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
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. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Binary Wheels and universal builds on OS-X
Wheel already supports compound tags. Just like py2.py3-none-any a tag py3-none-x86.ppc (with real platform names) would work. Does that make sense for Mac? On May 31, 2013 6:30 PM, Chris Barker - NOAA Federal chris.bar...@noaa.gov wrote: HI Folks, A few of us over on the pythonmac list have been hashing out how best to support binary packages on OS-X. The binary wheel option seems very promising. However, there is one Mac-specific issue that does not seem to be addressed: On OS-X, binaries can be universal -- what this means is that they have more than one binary architecture embedded in a single file; the system selects the right one at run time. Both executables and dynamic libraries can be universal. In theory, an universal binary can currently contain up to 4 architectures: 32+64 bit PPC and 32+64bit x86 In practice, 64 bit PPC was never broadly used, and 32bit PPC is fading fast. Nevertheless, both 32 and 64 Intel systems are pretty common, and who knows what there may be in the future (you never know with Apple...) The binary builds of Python served up on the python.org web site have supported universal builds for years -- currently there are two options: 32bit PPC+x86 or 32+64bit x86. It's not a single build, as it turns out it's hard to support both up to date x86_64 and PPC with the same compiler. In these builds, the configuration is set up so that distutils will build universal extensions that match the architectures included in the builds. This makes it pretty easy to build binary packages, and/or full app distributions (py2app) that are universal as well. setuptools' easy_install supports binary eggs, but always choked on universal builds -- it didn't know how to identify what matched the system. It would be really nice if future tools could identify and install the correct binary wheels for universal builds. I've taken a look at PEP 427, and see this: platform tag E.g. 'linux_x86_64', 'any'. That looks to me like there is a built-in assumption that a wheel is either specific to a single architecture, or any -- so no way to specify that it may have multiple architectures. So I propose that platform tag allow a list of some sort: ['macosx-10_6_i386', 'macosx_10_6-x86_64'] or, I suppose to keep it simple, a single string: 'macosx_10_6_i386+macosx_10_6_x86_64' or 'macosx_10_6_i386+x86_64' If so, then a binary wheel could be built (and discovered) that supported multiple architectures. Then how would an installer ( pip? ) identify the right one? This is a bit tricky. PEP 425 states: The platform tag is simply distutils.util.get_platform() with all hyphens - and periods . replaced with underscore On my system right now, I have 32bitPPC + 32bit i386 universal python, running on an intel system: In [2]: distutils.util.get_platform() Out[2]: 'macosx-10.3-i386' So we may want to patch get_platform() to support universal builds - or add anther function or something -- you may sometimes what to know what you are running right now, and other times want to know how the current python is built. (note that while distutils can build universal binaries, it's not very smart about it -- all is does is grab the compiler and linker flags from the Makefile, which include multiple -arch flags. Even if there is an easy way to query the system, that leaves the question of what to do. If a user wants to intall a package into a universal python, will the installer only accept a binary wheel with all the supported architectures? or one with only the currently running one? Anyway, it would be nice to be able to get this stuff to just work with universal binaries on the Mac. Thoughts, ideas? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
On Fri, May 31, 2013 at 6:33 PM, Trishank Karthik Kuppusamy t...@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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
On Fri, May 31, 2013 at 4:45 PM, Trishank Karthik Kuppusamy t...@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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
