Mailman 3 June 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

503 errors from PyPI
by Paul Moore 22 Feb '14

22 Feb '14

Whenever I do a PyPI search at the moment, I get Error 503 backend read error backend read error Guru Meditation: XID: 477806858 ________________________________ Varnish cache server Paul

3 6

Upcoming changes to PEP 426/440
by Nick Coghlan 19 Jul '13

19 Jul '13

Donald has been continuing his data modelling work for Warehouse (aka PyPI 2.0: https://github.com/dstufft/warehouse) and found that the *_requires/*_may_require split for dependencies was significantly more painful to work with than I had expected. Accordingly, I'm making some adjustments to the way dependencies are defined to bring them more into line with the way the contributors field and contact metadata works: 1. The "*_may_require" fields are all going away (leaving only the "*_requires" fields) 2. The "*_requires" fields are becoming lists of "dependency specifier" mappings rather than strings 3. A dependency specifier is now a mapping with the following fields: * "install": the installation specifier for the dependency * "extra": as per the current PEP (for conditional dependencies) * "environment": as per the current PEP (for conditional dependencies) 4. The "install" subfield is compulsory, the other two are optional (as now, using either of the latter creates a "conditional dependency", while dependency declarations with only the "install" subfield are unconditional) 5. An installation specifier is what PEP 426 currently calls a dependency specifier: the "name [extras] (constraints)" format. They will get their own top level section (similar to the existing Extras and Environment markers sections) In addition to those changes, I'll also be making a change to the recommended handling of virtual distributions (again based on Donald's feedback): integration tools should NEVER look at the "Provides" listings on a public index server to satisfy unmet dependencies. Instead, virtual distributions should be defined in such a way that whoever first invents the specific virtual distribution name registers it on PyPI, using the dependency metadata to pull in a default implementation. That's the only way to manage virtual distributions on a public index server that isn't vulnerable to later hijacking simply by registering a distribution with that name. As part of documenting that, I'll probably give the notion of "Virtual distributions" their own top level section (these are distributions that don't have any code of their own - they just declare dependencies on other projects to make them easy to install as a group, or to define the default provider for a dependency that may be satisfied by any one of multiple distributions). Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

5 40

complicated setup
by Ethan Furman 29 Jun '13

29 Jun '13

Here's my file layout: <root> / |- setup.py | |- enum / |- __init__.py | |- py2_enum.py | |- py3_enum.py | |- test / |- test_enum.py | |- py2_test_enum.py | |- py3_test_enum.py __init__ and test_enum are both smart enough to pull in the correct code when imported. The issue I am having is this: --8<-------------------------------------------------------------- ethan@hydra:~$ sudo easy_install enum34 [sudo] password for ethan: Searching for enum34 Reading http://pypi.python.org/simple/enum34/ Best match: enum34 0.9 Downloading http://pypi.python.org/packages/source/e/enum34/enum34-0.9.zip#md5=4717b8c3… Processing enum34-0.9.zip Writing /tmp/easy_install-sB55B5/enum34-0.9/setup.cfg Running enum34-0.9/setup.py -q bdist_egg --dist-dir /tmp/easy_install-sB55B5/enum34-0.9/egg-dist-tmp-qUYAv5 SyntaxError: ('invalid syntax', ('build/bdist.linux-x86_64/egg/enum/py3_enum.py', 211, 43, ' def __call__(cls, value, names=None, *, module=None, type=None):\n')) SyntaxError: ('invalid syntax', ('build/bdist.linux-x86_64/egg/enum/test/py3_test_enum.py', 630, 47, ' class AutoNumberedEnum(Enum, metaclass=auto_enum):\n')) zip_safe flag not set; analyzing archive contents... SyntaxError: ('invalid syntax', ('/usr/local/lib/python2.7/dist-packages/enum34-0.9-py2.7.egg/enum/py3_enum.py', 211, 43, ' def __call__(cls, value, names=None, *, module=None, type=None):\n')) SyntaxError: ('invalid syntax', ('/usr/local/lib/python2.7/dist-packages/enum34-0.9-py2.7.egg/enum/test/py3_test_enum.py', 630, 47, ' class AutoNumberedEnum(Enum, metaclass=auto_enum):\n')) Adding enum34 0.9 to easy-install.pth file Installed /usr/local/lib/python2.7/dist-packages/enum34-0.9-py2.7.egg Processing dependencies for enum34 Finished processing dependencies for enum34 --8<-------------------------------------------------------------- distutils is trying to load the py3 versions, which of course fails on a py2 install. The package installs successfully anyway, but if I were a user I would be wondering if the install was trustworthy. It seems to me that I need to either have distutils only install the version appropriate files, or to not try to scan the version inappropriate files, but at this point I do not know how to do either. Any pointers would be greatly appreciated. -- ~Ethan~

7 15

Download Counts on PyPI
by Donald Stufft 29 Jun '13

29 Jun '13

Download counts have (kind of) been re-enabled on PyPI. The new download counts work as so: * At the bottom of a detail page there is rolling tallies for the last day, the last week, and the last month[1] * The API exposes total download counts per file still. * The rolling counts update more or less in real time while the total counts in the API update hourly. * We no longer incorporate download counts from mirrors, making the mirroring infrastructure a tree and not a federation. [1] Only the last day is enabled currently, once more data is available the last week and last month will also be enabled. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

4 7

setuptools 0.8 on pypi?
by Peter Sabaini 28 Jun '13

28 Jun '13

Installation instructions for setuptools, eg. here[1], mention setuptools 0.8 as a download from pypi. However, pypi doesn't seem to carry version 0.8, only up to 0.7.4[2]. Are the installation instructions still work-in-progress, and is 0.7.4 the recommended version ATM? Thanks for the clarification, peter. [1] https://bitbucket.org/pypa/setuptools [2] https://pypi.python.org/pypi/setuptools

3 4

PEP 440 and prefix matching
by Vinay Sajip 27 Jun '13

27 Jun '13

All the examples of explicit prefix matching in PEP 440 show only release clause components, but it's not explicitly stated whether that's specifically intended. For example, are prefix matching clauses such as == 1.2.dev0.* != 1.2.post1.* allowed? Regards, Vinay Sajip

4 4