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

Installation
by vikash agrawal 17 Apr '12

17 Apr '12

hi Everyone, - I am using Python 2.7, so how do I install pysetup. though when I install distutils1.0a3 I do see distutils module in my interactive session but I dont see any pysetup being installed - Also, I had previously come in contact with merwok and I would be applying in GSoC this year under PSF for distutils2 project (as I believe PSF will be under GSoC and distutils will surely be accepted), so I am writing to seek help on what all things should be my target, and how do I move ahead. - Currently, I am trying to work on the ]issue 12944 but due to certain constraints things are not geared up, though I hope they would soon be :) - Please guide me and drop-in all your suggestions Regards Vikash Agrawal -- sent via HTC Sensation

3 4

[buildout] branches languishing? (site-packages and distutils scripts)
by Chris Withers 02 Apr '12

02 Apr '12

Hi All, I'm wondering what the state of play is with the following branches: reinout-scripts gary-4-include-site-packages What more needs to happen for these to get merged to trunk and a release made? cheers, Chris

10 28

[ANNOUNCE] pypiserver 0.5.1 - minimal pypi server
by Ralf Schmitt 23 Feb '12

23 Feb '12

Hi, I've just uploaded pypiserver 0.5.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 easy_install pypiserver). It doesn't have any external dependencies. http://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 version 0.5.1 ------------------------- - make 'pypi-server -U' compatible with pip 1.1 -- Cheers, Ralf

1 0

buildout: supporting += and -= in <=-style extends
by Vincent Pelletier 21 Feb '12

21 Feb '12

Hi. To properly factorise a .cfg I write, I use <=-style section extension. Some of the properties I define would take advantage of += operator, but "[buildout]\nextends = ..."-style extension. Wouldn't it be convenient if it worked internally to a file as well ? I've poked around in the code, and found that it's not trivial to implement (calling existing _update_section function is not enough, as that calls "update" on its first parameter and expects values to be pairs). Also, it would create ambiguous outcome when a section would contain <= and its file would extend another file containing an homonym section... Do anyone have an idea of how to implement this feature ? The best I could come up with is based on doubling "+" or "-" (rightmost is for "[buildout]\nextends = ..." extension when used, leftmost is for "<="extension) when used. The outcome looks logical enough, but I'm not sure input is clear enough to be The Right Way. Same-name extends (already works in current code): a.cfg: [foo] color = blue b.cfg: [buildout] extends = a.cfg [foo] color += green Outcome: color = blue green Different-name extends: b.cfg: [bar] color = red [foo] <= bar color += green Outcome: color = red green Both extends: a.cfg: [foo] color = blue b.cfg: [buildout] extends = a.cfg [bar] color = red [foo] <= bar color ++= green Outcome: color = blue red green Another example: Input as above, except: [bar] color = red green blue [foo] <= bar color -+= green Outcome: color = red Also, a few rants over the current implementation: 1. foo ++= bar is the same as foo += bar (for any number of extra "+") Likewise for "--=" 2. foo += bar will create a "foo +" property if [buildout] doesn't contain "extends" (ie, wouldn't it be more consistent to always remove/strip all "+" and "-" ?) 3. foo -+=bar will create a "foo -" property if [buildout] contains an "extends" (and if it doesn't, see 2.). Likewise for "+-=", "+-+=", etc. 4. "foo\t+=bar" (I mean literal tab char) will create a "foo\t" property (because rstrip is called with a parameter which only contains space as a whitespace char) I'm not saying those inputs make sense. I think current handling gives surprising results, and that alone is bad IMHO. Regards, -- Vincent Pelletier ERP5 - open source ERP/CRM for flexible enterprises

1 0

buildout: [PATCH] test extension precedence
by Vincent Pelletier 21 Feb '12

21 Feb '12

Hi. In my attempt to fix bug LP#605017, I broke "<=" precedence with patch on #2. I now submitted patch on #5 which preserves precedence. Also, I wrote attached tests for both extension forms: - <= ... - [buildout]\nextends = ... Please commit them if they are welcome. Note: I'm unsure of desired naming scheme, nor if there is any official naming unambiguously referring to each of those extensions, nor if it's the right file to put them in... Regards, -- Vincent Pelletier ERP5 - open source ERP/CRM for flexible enterprises

1 0

What do I need to run setup.py on Windows?
by Mark Sienkiewicz 14 Feb '12

14 Feb '12

Hi, I'm trying to use "setup.py install" to install python packages that include C extensions. I have Windows/XP, the 32 bit Python 2.7 binary downloaded from python.org and the 32 bit numpy binary downloaded from numpy.org. I don't seem to be able to get a working C compiler. At first, I read that you need Microsoft Visual Studio Express 2008. This is a 32 bit only C/C++ compiler, but that is ok because the Python and Numpy that I need are 32 bit executables. Well, I still get errors about a missing "basetsd.h". The solution I found online is to install "Windows SDK", which I found at http://www.microsoft.com/download/en/details.aspx?id=18950 The heading at the top of the page says "Windows 7", but under "Supported Operating Systems" it lists Windows/XP. I still get errors because basetsd.h is not found. In the interests of seeing if anything works at all, I made an empty file named c:\Python27\include\basetsd.h hoping I might get to see some different errors. I did. Apparently, basetsd.h does not contain anything I need, because "setup.py build" can compile the C code now. The link stage fails like this: c:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:C:\Python27\libs /LIBPATH:C:\Pyth on27\PCbuild /EXPORT:init_combine build\temp.win32-2.7\Release\src/_combinemodule.obj /OUT:build\lib.win32-2.7\stsci\image\_combine. pyd /IMPLIB:build\temp.win32-2.7\Release\src\_combine.lib /MANIFESTFILE:build\temp.win32-2.7\Release\src\_combine.pyd.manifest LINK : fatal error LNK1104: cannot open file 'kernel32.lib' error: command '"c:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.exe"' failed with exit status 1104 So, somehow I need to have basetsd.h and kernel32.lib; neither of them is provided by the compiler and neither is provided by Windows SDK. I've run out of ideas about where to look for documentation and what other things to try. Can anybody offer me any suggestions? Mark S.

1 1

Installing to c:\Program Files\
by Torquil Macdonald Sørensen 10 Feb '12

10 Feb '12

Hi! Is the distutils system suited for installation of a python program to a subfolder of c:\Program Files\ ? I can generate an msi file using the bdist_msi method, but the resulting msi installer puts the files in c:\python27\lib\site-packages (or something like that). My python program basically consists of a python script, two python modules and some text files. None of this should be available to other python programs, so I want it all to be installed in a subdirectory of Program Files. This makes sense, right? The program itself is already capable to be launched from any folder. Can distutils create an msi file for my python program that does what I want? Or should I use some other tool? I want to create an installer that uses the Windows "Add/Remove programs" system, and hopefully allows upgrading to newer program versions without leaving multiple versions installed. Thanks, Torquil Sørensen

2 3