Mailman 3 October 2012 - 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

mebs, the meta-build system
by Daniel Holth 06 Feb '13

06 Feb '13

or, removing distutils without replacing it. ** not an actual project ** Proposing mebs, the meta-build system. What if pip did not depend on setuptools or distutils and the stdlib did not include distutils or any other build system? Instead, the installer can only install binary packages, and build systems do not install but only build binary packages. A very simple meta-build system "mebs" is used to recognize sdists and build binary packages. Build systems provide plugins having three methods, .recognize() .metadata() .build() An installer downloads an sdist. For each installed build plugin, .recognize(dir) is called. The first plugin to return True is used. The plugin's .metadata(dir) is called, returning Metadata 1.3+ format metadata in a simple email.parser.Parser() multi-dict interface. Used to fetch any build/install requirements. .build(dir) is called to create the binary package. The installer installs the binary package. The first time you download an sdist, the build system/installer has to download a pre-built binary package of distutils (because it has been removed from the standard library). Alternatively a minimal setup.cfg build_system=x is consulted to download something other than distutils, the newly installed build plugin recognizes the sdist, and the package is built and installed. You wouldn't have to actually remove distutils, but every other build system could be made to compete with it on equal footing. Binary packages are used as the lingua franca because, unlike build systems, binary packages are simple enough that there can be multiple compatible implementations.

4 5

Some clarifications and/or corrections to PEP 376
by Paul Moore 07 Jan '13

07 Jan '13

I've been looking at the details of PEP 376 (Database of Installed Python Distributions) and there are a couple of aspects that I don't think work properly alongside PEP 370 (Per-user site-packages directory).. 1. The dist-info directory for a distribution is stated as being "located in the site-packages directory". It's not clear how this is intended to work in a PEP 370 world with multiple site-packages. What I propose is that the description be changed to be worded in terms of sysconfig-style locations: the dist-info directory is located in whichever of purelib or platlib is used by the distribution. When the distribution uses both, purelib is preferred, when it uses neither (!) purelib is used. In nearly all cases, this is the same as currently. The exceptions are posix_home (where the directory name isn't "site-packages" but its function is the same), posix_prefix (where purelib and platlib differ, and PEP 376 is currently ambiguous as to which is implied), and any custom schemes that might be created (where PEP 376 is silent, and this proposal has the benefit of at least being specific). I do not believe this changes any actual practice - as far as I have been able to determine any code using dist-info at the moment follows this proposal in the corner cases where it differs from PEP 376. 2. File paths in RECORD are stated as being relative to the "base location" as long as the files sit under that location, or under the "install prefix" where that is above the base location. That's a messy but precise way of saying you can go up a bit as long as you stay within sys.prefix. (Other paths are platform format absolute paths, which is an ugly discrepancy but the only really viable option). Again, this doesn't work as I'd expect it should in a PEP 370 user site-packages. In this case, the answer isn't quite as clear. I would suggest, looking at the schemes defined in sysconfig, allowing any files located in one of the defined sysconfig paths (for the current scheme) to be recorded as relative paths. The paths should be relative to whichever of purelib and platlib was chosen in (1) above. The exception is that where pureXXX and platXXX do not use the same base (posix_prefix and possibly custom schemas) it should not be allowed to have a relative path from a pureXXX to a platXXX or vice versa. That equates to something slightly stricter than the current scheme (although not in a way that's likely to be used in practice), but using the appropriate one of {base} or {userbase} rather than sys.prefix. As noted, the two exceptions are custom schemes (where PEP 376 is silent and would probably end up effectively mandating platform absolute paths throughout) and posix_prefix, where platlib/platinclude/platstdlib are located under {platbase} rather than {base} and the current proposal would probably allow relative paths to be used a little more often that PEP 376 allows. Current practice that I've seen here is not as clear cut, but mostly in the sense that code doesn't consider the corner cases at all, and probably only follows PEP 376 by luck, if at all... Comments would be appreciated. I'm pretty happy that my proposal for (1) is an improvement. With (2) I'm concerned about the posix_prefix case, particularly as I'm a Windows developer and my understanding of Python's layout on POSIX is limited. But I honestly don't think it's possible to do much better than my proposal, and I do think that PEP 376 as it stands now is distinctly worse because it doesn't consider PEP 370 or the posix_prefix case. Also, while these proposals are not 100% backward compatible, I don't believe they change behaviour in the most common scenarios, and given that PEP 376 currently has limited adoption (mainly in distutils2, I believe) I'd suggest that the minor compatibility break now is better than keeping the current system until it's more widely adopted and there are more users to impact. Obviously I'd be looking for views from Tarek and Éric in particular here, as it's their code in distutils2 that would be directly impacted. Paul.

4 10

Re: [Distutils] [Python-Dev] accept the wheel PEPs 425, 426, 427
by Daniel Holth 13 Nov '12

13 Nov '12

I think Metadata 1.3 is done. Who would like to czar? On Oct 22, 2012 12:53 PM, "Daniel Holth" <dholth(a)gmail.com> wrote: > http://hg.python.org/peps/rev/50e8ea1a17a0 > > Based on the other "required" field's absence in the wild, only > "Metadata-Version", "Name", "Version", and "Summary" are required. > Hopefully a clearer explanation of 0, 1, or many occurrences of each > field. >

9 15

accept the wheel PEPs 425, 426, 427
by Daniel Holth 10 Nov '12

10 Nov '12

I'd like to submit the Wheel PEPs 425 (filename metadata), 426 (Metadata 1.3), and 427 (wheel itself) for acceptance. The format has been stable since May and we are preparing a patch to support it in pip, but we need to earn consensus before including it in the most widely used installer. Wheel is a binary packaging format that is mostly based on the phenomenal work done by 'packaging' as PEP 376 et al. The resulting packages solve packaging problems by being installable without setup.py or any variation of distutils, lxml can be installed in 0.7 seconds, and a simple installer is just "unzip" inside site-packages. Wheel installers know about the major version number of the spec itself, and will refuse to install version 2.0 wheels if they do not understand them, so the format can be changed down the line. Let me know what I need to do to get it accepted, if anything needs to be added or revised, or, preferably, that it is awesome and you want to use it ASAP. Thanks, Daniel Holth

8 24

How to upgrade distribute with distribute_setup if necessary?
by anatoly techtonik 03 Nov '12

03 Nov '12

I can't install Sphinx in a Python 3.2 directory with distribute 0.6.13 installed due to a bug in outdated distribute. Sphinx uses distribute_setup.py and if no setuptools installed it fetches new version where there is no such problem. The check is the following code: try: from setuptools import setup, find_packages except ImportError: import distribute_setup distribute_setup.use_setuptools() from setuptools import setup, find_packages What is the proper way to modify it to make distribute_setup.py upgrade distribute if necessary? -- anatoly t.

3 5

[ANN] wheel@librelist.com mailing list
by Daniel Holth 02 Nov '12

02 Nov '12

I've started a list wheel(a)librelist.com to discuss the implementation of the 'wheel' binary package format, instead of discussing it all on this list. Mail the list to join. We are hoping to have support merged into pip soon. Daniel H

2 2