Mailman 3 June 2013 - Distutils-SIG

Proposal of a new PyPI mirror
by Bojie Li 04 Jun '13

04 Jun '13

Hello, I'm from University of Science and Technology of China and have set up a PyPI mirror at http://pypi.mirrors.ustc.edu.cn/ This mirror is synced using bandersnatch every 5 minutes, which is compliant with PEP-381. Can we become an official PyPI mirror? Thanks, -- Linux User Group University of Science and Technology of China Homepage: http://lug.ustc.edu.cn/ E-Mail: lug(a)ustc.edu.cn Bojie Li <bojieli(a)gmail.com>

1 0

Re: [Distutils] Binary Wheels and "universal" builds on OS-X
by Chris Barker - NOAA Federal 03 Jun '13

03 Jun '13

Darn! this slipped off the list -- I hate it when lists aren't set with the reply-to address as the list... On Mon, Jun 3, 2013 at 3:47 PM, Daniel Holth <dholth(a)gmail.com> wrote: > ppc is not completely dead? I have one under my desk, though truth be told, I haven't turned it on in a good while... Which is a good point, of course, we really only have one type of "universal" build to support, and even that one may be obsolete before too long -- not sure how many 32bit only macs are still around. > That would make sense. Can you come up with code to detect that a > newly compiled extension is universal, and that a Python is? can it be platform-dependent? i.e. use a mac-only system call? -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

2 1

Fwd: Binary Wheels and "universal" builds on OS-X
by Chris Barker - NOAA Federal 03 Jun '13

03 Jun '13

Folks, Accidentally let this slip off the list... -Chris ---------- Forwarded message ---------- From: Chris Barker - NOAA Federal <chris.barker(a)noaa.gov> Date: Mon, Jun 3, 2013 at 1:33 PM Subject: Re: [Distutils] Binary Wheels and "universal" builds on OS-X To: Daniel Holth <dholth(a)gmail.com> On Mon, Jun 3, 2013 at 9:57 AM, Daniel Holth <dholth(a)gmail.com> wrote: >> A potential full name: >> >> my_package-3_2-cp27-cp27-macosx_10_3_i386.macosx_10_3_ppc.whl >> >> (Im a little confused about python version tag vs. ABI tag, in the >> case of a compiled extension...) > The Python Tag is the Python implementation or language version. It > lets you indicate compatibility with only CPython or Jython or PyPy > even if you do not have compiled extensions: so, in this case, is is right to put cp27 in there twice? > The platform tag is the OS+architecture. yeah, kind of wish these were separate, but not really a big deal. > For compatibility matching the tags are expanded to the Cartesian > product of the string.split('.') of each of the python, abi, and > platform tags. This is mostly only useful when only one part of the > tag is compound. > http://www.python.org/dev/peps/pep-0425/#compressed-tag-sets OK -- I think I've got it... > If this doesn't work then it might be more useful to invent a tag like > "macosx_10_3_universal" for some value of universal. hmm -- the trick is that "universal" implies that the binary is, well, universal, but what t really means is "has more than one architecture in it". In practice, there are only a few combinations likely to see use, so maybe just defining a few (only two, now, on the python.org site...) tags makes sense: macosx_10_3_i386_ppc and macosx_10_6_i386_x86_64 -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

1 0

[issue150] ssl_support.py: 1868:04732ee16e7e broke '_dnsname_to_pat'
by Tres Seaver 03 Jun '13

03 Jun '13

New submission from Tres Seaver: That Hg commit reference dropped the import of 're', which breaks the '_dnsname_to_pat' fallback function. I reported this on bitbucket: https://bitbucket.org/pypa/setuptools/issue/8 and pushed changes for a pull request there: https://bitbucket.org/pypa/setuptools/pull-request/4 but Jason thinks the 0.6 branch is still primarily managed here and in SVN. The bug breaks the zope.org buildouts, which are still using the 0.6 nightlies while the 0.7 release waits in the wings. ---------- assignedto: pje messages: 721 nosy: pje, tseaver priority: urgent status: unread title: ssl_support.py: 1868:04732ee16e7e broke '_dnsname_to_pat' _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue150> _______________________________________________

1 0

Sooner or later, we're going to have to be more formal about how we name packages.
by Jim Fulton 03 Jun '13

03 Jun '13

In the Python community, we've been pretty laid back about how we name packages. When we were small, this made sense. It doesn't make sense any more. We should not have to come up with a process for recognizing squatters on simple package names. We should have something more systematic, IMO. Unfortunately, I think the sanest way of avoiding most package name issues is to base them on domains, as is done in the Java world. This goes against the Python philosophy of preferring flat to nested, but I still think it's better than trying to police squatters, or to encouraging races to claim top-level names. For a while, many of us have been pretty careful to use namespaces for new packages to mitigate this issue. For example, the zc namespace is a shorter version of com.zope, but at some point, it won't be fair for us to claim zc for ourselves. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton

12 29

A process for removal of PyPi entries
by Radomir Dopieralski 03 Jun '13

03 Jun '13

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

15 30

Re: [Distutils] Setuptools 0.7 final available for download
by Jason R. Coombs 02 Jun '13

02 Jun '13

From: Paul Moore [mailto:p.f.moore@gmail.com] Sent: Sunday, 02 June, 2013 14:03 One other question that I can't see covered by the CHANGES and README files. Does setuptools 0.7 support dist-info directories the same way that recent versions of distribute did? The dist-info support is critical to wheel support in pip. Yes, unless otherwise specified in the merge docs, Setuptools 0.7 includes all of Distribute.

1 0

Re: [Distutils] Setuptools 0.7 final available for download
by Jason R. Coombs 02 Jun '13

02 Jun '13

Hi Paul. From: Paul Moore [mailto:p.f.moore@gmail.com] Sent: Sunday, 02 June, 2013 13:13 On 2 June 2013 16:42, Jason R. Coombs <jaraco(a)jaraco.com <mailto:jaraco@jaraco.com> > wrote: For convenience, I've also added experimental .msi installers for Windows for Python 3.3 and Python 2.7. Work may continue on these in the future, but as the documentation states, the recommended installation procedure is to use ez_setup.py. Please consider using wheel instead of msi. Or at least bdist_wininst. The msi format is opaque and cannot be converted to other formats. OTOH, setuptools is pure Python, so having binaries is a relative non-issue. Thanks. I need to learn wheel. I haven't yet done that. The reason I chose msi is because it is a binary distribution format that works on 64-bit Python (there still exists a bug in distutils where installers don't detect 64-bit python installations because the installer executable is 32-bit). The recommended installation technique on all platforms, much like Distribute, is to do a source install. One point - can I assume that the new version is written to run unchanged on all supported Python versions (2 and 3) so that it is possible to build a wheel using *any* version of Python and use it unchanged on any other? (I ask because I'd like to look at integrating setuptools 0.7 into virtualenv). Currently, Python 3 support is still using the same technique employed by distribute - namely, running 2to3 during install. So I don't believe it can be used unchanged on any Python version. Having a single code base for Python 2.4-3.3 is the top feature I want to develop as soon as the merge is complete and successfully adopted.

1 0

[ANN] pypiserver 1.1.1 - minimal private pypi server
by Ralf Schmitt 02 Jun '13

02 Jun '13

Hi, I've just uploaded pypiserver 1.1.1 to the python package index. pypiserver is a minimal PyPI compatible server. It can be used to serve a set of packages and eggs to easy_install or pip. pypiserver is easy to install (i.e. just 'pip install pypiserver'). It doesn't have any external dependencies. https://pypi.python.org/pypi/pypiserver/ should contain enough information to easily get you started running your own PyPI server in a few minutes. The code is available on github: https://github.com/schmir/pypiserver Changes in this version ----------------------- - add 'overwrite' option to allow overwriting existing package files (default: false) - show names with hyphens instead of underscores on the "/simple" listing - make the standalone version work with jython 2.5.3 - upgrade waitress to 0.8.5 in the standalone version - workaround broken xmlrpc api on pypi.python.org by using HTTPS -- Cheers Ralf

4 7