Mailman 3 May 2013 - Distutils-SIG

Two fixes (at last)
by Greg Ward 29 Apr '18

29 Apr '18

Hi all -- at long last, I have fixed two problems that a couple people noticed a while ago: * I folded in Amos Latteier's NT patches almost verbatim -- just changed an `os.path.sep == "/"' to `os.name == "posix"' and added some comments bitching about the inadequacy of the current library installation model (I think this is Python's fault, but for now Distutils is slavishly aping the situation in Python 1.5.x) * I fixed the problem whereby running "setup.py install" without doing anything else caused a crash (because 'build' hadn't yet been run). Now, the 'install' command automatically runs 'build' before doing anything; to make this bearable, I added a 'have_run' dictionary to the Distribution class to keep track of which commands have been run. So now not only are command classes singletons, but their 'run' method can only be invoked once -- both restrictions enforced by Distribution. The code is checked into CVS, or you can download a snapshot at http://www.python.org/sigs/distutils-sig/distutils-19990607.tar.gz Hope someone (Amos?) can try the new version under NT. Any takers for Mac OS? BTW, all parties involved in the Great "Where Do We Install Stuff?" Debate should take a good, hard look at the 'set_final_options()' method of the Install class in distutils/install.py; this is where all the policy decisions about where to install files are made. Currently it apes the Python 1.5 situation as closely as I could figure it out. Obviously, this is subject to change -- I just don't know to *what* it will change! Greg -- Greg Ward - software developer gward(a)cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913

2 1

Package versioning
by Timothy Docker 29 Apr '18

29 Apr '18

Hi all, I've been aware that the distutils sig has been simmerring away, but until recently it has not been directly relevant to what I do. I like the look of the proposed api, but have one question. Will this support an installed system that has multiple versions of the same package installed simultaneously? If not, then this would seem to be a significant limitation, especially when dependencies between packages are considered. Assuming it does, then how will this be achieved? I am presently managing this with a messy arrangement of symlinks. A package is installed with its version number in it's name, and a separate directory is created for an application with links from the unversioned package name to the versioned one. Then I just set the pythonpath to this directory. A sample of what the directory looks like is shown below. I'm sure there is a better solution that this, and I'm not sure that this would work under windows anyway (does windows have symlinks?). So, has this SIG considered such versioning issues yet? Cheers, Tim -------------------------------------------------------------- Tim Docker timd(a)macquarie.com.au Quantative Applications Division Macquarie Bank -------------------------------------------------------------- qad16:qad $ ls -l lib/python/ total 110 drwxr-xr-x 2 mts mts 512 Nov 11 11:23 1.1 -r--r----- 1 root mts 45172 Sep 1 1998 cdrmodule_0_7_1.so drwxr-xr-x 2 mts mts 512 Sep 1 1998 chart_1_1 drwxr-xr-x 3 mts mts 512 Sep 1 1998 Fnorb_0_7_1 dr-xr-x--- 3 mts mts 512 Nov 11 11:21 Fnorb_0_8 drwxr-xr-x 3 mts mts 1536 Mar 3 12:45 mts_1_1 dr-xr-x--- 7 mts mts 512 Nov 11 11:22 OpenGL_1_5_1 dr-xr-x--- 2 mts mts 1024 Nov 11 11:23 PIL_0_3 drwxr-xr-x 3 mts mts 512 Sep 1 1998 Pmw_0_7 dr-xr-x--- 2 mts mts 512 Nov 11 11:21 v3d_1_1 qad16:qad $ ls -l lib/python/1.1 total 30 lrwxrwxrwx 1 root other 29 Apr 10 10:43 _glumodule.so -> ../OpenGL_1_5_1/_glumodule.so lrwxrwxrwx 1 root other 30 Apr 10 10:43 _glutmodule.so -> ../OpenGL_1_5_1/_glutmodule.so lrwxrwxrwx 1 root other 22 Apr 10 10:43 _imaging.so -> ../PIL_0_3/_imaging.so lrwxrwxrwx 1 root other 36 Apr 10 10:43 _opengl_nummodule.so -> ../OpenGL_1_5_1/_opengl_nummodule.so lrwxrwxrwx 1 root other 27 Apr 10 10:43 _tkinter.so -> ../OpenGL_1_5_1/_tkinter.so lrwxrwxrwx 1 mts mts 21 Apr 10 10:43 cdrmodule.so -> ../cdrmodule_0_7_1.so lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 chart -> ../chart_1_1 lrwxrwxrwx 1 root other 12 Apr 10 10:43 Fnorb -> ../Fnorb_0_8 lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 mts -> ../mts_1_1 lrwxrwxrwx 1 root other 15 Apr 10 10:43 OpenGL -> ../OpenGL_1_5_1 lrwxrwxrwx 1 root other 33 Apr 10 10:43 opengltrmodule.so -> ../OpenGL_1_5_1/opengltrmodule.so lrwxrwxrwx 1 root other 33 Apr 10 10:43 openglutil_num.so -> ../OpenGL_1_5_1/openglutil_num.so lrwxrwxrwx 1 root other 10 Apr 10 10:43 PIL -> ../PIL_0_3 lrwxrwxrwx 1 mts mts 10 Apr 10 10:43 Pmw -> ../Pmw_0_7 lrwxrwxrwx 1 root other 10 Apr 10 10:43 v3d -> ../v3d_1_1

3 2

[Distutils-sig] distutils charter and interscript
by John Skaller 29 Apr '18

29 Apr '18

3 2

error in windows 7 installation
by Manuel López 13 May '14

13 May '14

Hello Everybody: I am trying to install distribute-0.6.25 in a windows 7 machine. I have python 2.7.3 in 32 bits, although the machine is 64 bits. I installed the 32 bit python version because I want to install ipython and there is no 64 bit builds of the Windows installer for ipython. In any case, upon installing disuitils with python setup.py install I get the following error error: C:\manuel\prog_red\python\distribute-0.6.25\distribute-0.6.25\setuptools\cli-32.exe: No such file or directory Any help will be greatly appeciated. Thanks, Manuel -- Manuel López Mariscal Depto. de Oceanografía Física/CICESE malope(a)cicese.mx

2 1

PyPI Download Counts
by Donald Stufft 14 Jun '13

14 Jun '13

Hello! As you have have noticed the download counts on PyPI are no longer updating. Originally this was due to an issue with the script that processes these download counts. However I have now removed the download counts from the PyPI webui and their use via the API is considered deprecated. There are numerous reasons for their removal/deprecation some of which are: - Technically hard to make work with the new CDN - The CDN is being donated to the PSF, and the donated tier does not offer any form of log access - The work around for not having log access would greatly reduce the utility of the CDN - Highly inaccurate - A number of things prevent the download counts from being inaccurate, some of which include: - pip download cache - Internal or unofficial mirrors - Packages not hosted on PyPI (for comparisons sake) - Mirrors or unofficial grab scripts causing inflated counts (Last I looked 25% of the downloads were from a known mirroring script). - Not particularly useful - Just because a project has been downloaded a lot doesn't mean it's good - Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad In short because it's value is low for various reasons, and the tradeoffs required to make it work are high It has been not an effective use of resources. The API will continue to return values for it in order to not break scripts, however in the future all these values will be set to 0. The Web UI has been modified to no longer display it. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

11 28

Draft PEP for JSON based metadata published
by Nick Coghlan 06 Jun '13

06 Jun '13

After preliminary reviews by Donald and Daniel, I have now pushed the first complete draft of the JSON-based metadata 2.0 proposal to python.org PEP 426 (metadata 2.0): http://www.python.org/dev/peps/pep-0426/ PEP 440 (versioning): http://www.python.org/dev/peps/pep-0440/ With the rationale and commentary, they're over 3000 lines between them, so I'm not attaching them here. The rationale for many of the changes is at the end of each PEP, along with some comments on features that I have either rejected or deliberately chosen to defer to the next revision of the metadata (at the earliest). Those with BitBucket accounts may also comment inline on the drafts here: PEP 426: https://bitbucket.org/ncoghlan/misc/src/05d3586464b10d6a04a35409468269d7c89… PEP 440: https://bitbucket.org/ncoghlan/misc/src/05d3586464b10d6a04a35409468269d7c89… Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

6 31

problems with sdist upload since CDN update
by kiorky 05 Jun '13

05 Jun '13

I got some random releasing (1 on 5 or 6 tries) problems since last pypi update. For example, with collective.ckeditor (3.6.10 tag on github), the sdist upload will randomly not upload the file without reporting any error on console: https://github.com/collective/collective.ckeditor/tree/3.6.10 -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF Pensez à l’environnement. N’imprimez ce courriel que si vous en avez vraiment besoin.

3 9

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

04 Jun '13

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/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

4 9

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

[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