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

Anyone home?
by James C. Ahlstrom 06 Jul '99

06 Jul '99

Hi, Is this sig active? Is anyone out there? Jim Ahlstrom

2 1

Add multiple frozen modules
by James C. Ahlstrom 30 Jun '99

30 Jun '99

Hi, I have been working with the Tools/freeze/freeze.py etc. utilities in order to build a Python binary with part of the Python library built in. I found out you-all have been working on this. But AFAIK we are not there yet. I see that using freeze.py will create a binary Python with the libs included in the frozen module. But: 1) The "script" argument to freeze.py is not optional. Some module is always frozen with the name __main__ and so it is always executed when Python starts up. This makes it impossible to create a python15.dll (or python15.so) which is general-purpose. That is, a shared binary Python with libraries but not a main program built in. Since the Python interpreter and libs must use exactly the same version, it is useful to link them together. 2) There is only one frozen module allowed, so no further use of frozen modules is possible. The frozen feature has been devoted to the Python libraries. This makes it impossible to make a python15.dll which can be used with a variety of python.exe programs with further frozen modules. Unix translation: A python15.so shared library for use with further python main programs containing frozen modules. I have code which solves both problems. But perhaps I have not understood Tools/freeze, and there is already a way to do this? I see there is a function PyImport_ExtendInittab() in import.c which adds entries to the table of built-in modules, which is sort of analogous to (2), but that this function is unused. (My code uses a different method.) Please let me know what you think. Is this useful enough to be added to Python? Or is it already there? Jim Ahlstrom

2 2

Put Python library into binary
by James C. Ahlstrom 25 Jun '99

25 Jun '99

Hello everyone, It looks like you have been working on putting the Python library into the binary. I looked in Tools/freeze at freeze.py. Please check my understanding of the following: 1) Use of freeze.py creates a frozen module with the Python library in it. 2) There is always a __main__.py program incorporated. 3) No further use of frozen modules is permitted since there is only one frozen module allowed. Number (2) and (3) are a problem for me, but maybe I am wrong about how this all works. Jim Ahlstrom

1 0

RE: [Crew] Wizards' Resolution to Zope/PIL/mxDateTime conflict?
by Jeffrey C. Jacobs 17 Jun '99

17 Jun '99

> -----Original Message----- > From: Tom Bryan [SMTP:tbryan@server.python.net] > Sent: June 17, 1999 12:19 PM > To: Crew List > Subject: Re: [Crew] Wizards' Resolution to Zope/PIL/mxDateTime > conflict? > > Perhaps this discussion should be moved to the PSA list or to the > comp.lang.python newsgroup. The Starship isn't going to be the only > computer with this problem. We juat are going to be one of the few > machines that currently has *many* third-party extensions to Python. As > Python grows in popularity, this problem is only going to get worse. In > the worst case scenario, people won't be able to use a Python solution > because the required third-party extensions conflict and they don't want > to kludge it all together themselves. > It seems to me perhaps the simplest solution is, dare I say it, Bureaucracy! Okay, now that I got you all riled up, let me explain. Right now, anyone can go write a Python package and post it up all over the place, helter-skelter. It may even appear on www.python.org. However, if I'm writing Package A and you have written package B unbeknownst to me, I might be stepping on your toes. That is to say, if my package does the same thing, so what? more choice to the hacker. The problem is when I CALL my module/package the same thing as you. It is this naming convention that needs to be cleaned up, as I see it. Rather than come up with some complex scheme of installation or some major changes to the python language, wouldn't it just be simpler to standardize our naming now, before Python does reach the 10,000,000 user mark? That is, rather then trying to come up with an installation-level solution, why not just have someone review all packages for conflicts on a first-come-first-serve basis? Set up a committee of Python certification which will basically go through each new package and install it on a max-install station. If there are no conflicts, the package is certified and the author gets official recognition. If there is conflict, a polite e-mail can be sent to the author suggesting he or she modify / change the name(s) chosen for his or her package to avoid future conflict potential. As for currently existing conflicts, there is of course the problem with install-base. The best thing I can suggest is a renaming of 1 or more existing packages to conform to the Python standard extension model. That is to say, there would then be two copies of the package available -- 1 with backwards-compatible naming and 1 which is the Python-certified name. Based on the desire of the package author / maintainer, the old names could be phased out as time goes by in new releases. Typically, the more ingrained a package is in an application, the less likely it is that a conflicting package will be installed on that system. Thus *hopefully* this should not effect any previous install of Python. It would probably be best when conflicts *do* occur to ask *both* pre-existing Package authors to try to come up with new names, so as to be more even-handed, though I'd suggest larger packages get priority. The best thing is, when Microsoft starts to see Python as a threat to its Visual xxx monopoly and starts to "embrace" Python with their new Visual P++ integrated development environment, and starts adding weird packages left, right and center, the Python certification committee can just "uncertify" the extensions and (hopefully) prevent the destruction of the language the same way they did Java. I think Mark Hammond would be heading Microsoft off at the pass, as it were WRT this issue though. What's more, we here at Starship seem to be the perfect candidate to be the "Python Package" machine, at least on the Unix / Linux side -- I should hope a similar all-install machine could be set up for Microsoft-based system verification, as well as Mac and any other OS which has a unique package list. > Does someone want to make an intelligent, concise post to one of the other > forums? comp.lang.python has enough posters who want to "improve" the > language. Perhaps we could direct their energy into a useful change. > I am sending a copy of this over there... Be Seeing You, Jeffrey.

3 2

complete GNU readline support, packaging issues
by Ovidiu Predescu 02 Jun '99

02 Jun '99

Hi, I've just started with Python and I discovered that the binding to the GNU readline is really basic. So about a week ago I started working on a binding for it and I have most of the work done. I need to finish the bindings for keymap functions and some of the functions in the completion part before the package could be considered complete. I started to investigate the ways to package the work I've done and I discovered the distutil package. I'm trying to write a setup.py file, but I need the following things and I didn't figure out how to express them: - the main C file is obtained by running the m4 program on a .m4 file. How can I specify this dependency and the rule for generating the C file? - I need to define a C preprocessor macro that contains the version of the readline library. The way the things are setup now is by running a configure script that determines the version of the library. Can I do this with setup.py? Thanks, -- Ovidiu Predescu <ovidiu(a)cup.hp.com> http://www.geocities.com/SiliconValley/Monitor/7464/

2 1

shared extensions that use other shared extensions
by Michael P. Reilly 01 Jun '99

01 Jun '99

Hi folks, I ran into a small problem this weekend while working on a potential redesign of _tkinter.c that I thought I should bring up here. This is not so much a change to distutils code, or the addition of a feature. But it is a big "gotcha" on UNIX, where shared objects could reside in different directories (as has been discussed here lately). Just to give a little rundown of the problem. A few weeks ago, someone on c.l.py asked if there was a Tcl interpreter extension. Some people (including myself) stated that there was one in Tkinter, but couldn't divorce yourself from Tk. So I got it in my head to make a Tcl module then redesign _tkinter.c to use that module instead. Now the problem: To be thread safe (especially with Tcl8.0), there is a global lock object used when entering all the Tcl/Tk code. This object should be shared between the two modules (it is using the same Tcl_Interp object). Not a problem, right? In the Python init_tkinter() function, simply import the Tcl module and get access to the global data in the shared module. The import.c code would load the dynamic modules and handle it. Not quite. When the _tkinter.so loads, it attempts to load the Tcl module shared object as well, not based on sys.path but on LD_LIBRARY_PATH (or what every was set at link-time). I got around this by making a PyCObject out of the Tcl lock object in the module, then accessing that inside init_tkinter(), thereby making no references to the Tcl module. Now to my point to all this. I have two, in fact. First, when writing modules, try not rely on global data in other Python modules unless it is thru the Python API. You might find that your runtime link-editor can't handle finding the shared library file. Second, it may not always be enough to place the shared object modules in site-packages or the like. I can easily imagine that SWIG might make references to something inadvertently that is outside the view that import.c (or the imp module) has of the world. -Arcege -- ------------------------------------------------------------------------ | Michael P. Reilly, Release Engineer | Email: arcege(a)shore.net | | Salem, Mass. USA 01970 | | ------------------------------------------------------------------------

1 0

extensions in packages
by hinsen＠dirac.cnrs-orleans.fr 01 Jun '99

01 Jun '99

Just van Rossum wrote: > foo.bar is registered as a "builtin" in config.c file as > > {"foo.bar", initbar}, > > (Hm, this is problemetic if the is a distinct global builtin module "bar") Or if any other package has a module "bar"! > find_module() should then first check sys.builtin_module_names with the > full name before doing anything else. (probably only when it is confirmed > that "foo" is a package.) All that would be doable, but the real problem is the name of the init function! Only one module can define a global symbol "initbar". So the one for foo.bar would have to be called "initfoo.bar" (or something similar). On the other hand, when the same module is used dynamically, the init function must be called "initbar" again (unless the current import mechanism is changed). Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen(a)cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------

8 20