Mailman 3 May 2004 - Distutils-SIG

Re: [Distutils] distutils install probs on suse 9.0
by Mats Wichmann 29 Apr '18

29 Apr '18

At 05:43 AM 5/18/2004, David Handy wrote: >On Tue, 18 May 2004, Floris van der Tak wrote: > >> my attempt to install the distutils on suse 9.0 (which provides python >> 2.3) fails: > >Why are you installing distutils on a system that already has Python 2.3 >installed? Python 2.3 normally comes with distutils as part of the Python >standard library. > >Did suse distribute a version of Python that had distutils removed? It should come from python-devel

2 1

Sample setup.py for Numeric Python
by Greg Ward 29 Apr '18

29 Apr '18

Hi again -- [cc'd to Paul Dubois: you said you weren't following the distutils sig anymore, but this directly concerns NumPy and I'd like to get your input!] here's that sample setup.py for NumPy. See below for discussion (and questions!). ------------------------------------------------------------------------ #!/usr/bin/env python # Setup script example for building the Numeric extension to Python. # This does sucessfully compile all the .dlls. Nothing happens # with the .py files currently. # Move this file to the Numerical directory of the LLNL numpy # distribution and run as: # python numpysetup.py --verbose build_ext # # created 1999/08 Perry Stoll __rcsid__ = "$Id: numpysetup.py,v 1.1 1999/09/12 20:42:48 gward Exp $" from distutils.core import setup setup (name = "numerical", version = "0.01", description = "Numerical Extension to Python", url = "http://www.python.org/sigs/matrix-sig/", ext_modules = [ ( '_numpy', { 'sources' : [ 'Src/_numpymodule.c', 'Src/arrayobject.c', 'Src/ufuncobject.c' ], 'include_dirs' : ['./Include'], 'def_file' : 'Src/numpy.def' } ), ( 'multiarray', { 'sources' : ['Src/multiarraymodule.c'], 'include_dirs' : ['./Include'], 'def_file': 'Src/multiarray.def' } ), ( 'umath', { 'sources': ['Src/umathmodule.c'], 'include_dirs' : ['./Include'], 'def_file' : 'Src/umath.def' } ), ( 'fftpack', { 'sources': ['Src/fftpackmodule.c', 'Src/fftpack.c'], 'include_dirs' : ['./Include'], 'def_file' : 'Src/fftpack.def' } ), ( 'lapack_lite', { 'sources' : [ 'Src/lapack_litemodule.c', 'Src/dlapack_lite.c', 'Src/zlapack_lite.c', 'Src/blas_lite.c', 'Src/f2c_lite.c' ], 'include_dirs' : ['./Include'], 'def_file' : 'Src/lapack_lite.def' } ), ( 'ranlib', { 'sources': ['Src/ranlibmodule.c', 'Src/ranlib.c', 'Src/com.c', 'Src/linpack.c', ], 'include_dirs' : ['./Include'], 'def_file' : 'Src/ranlib.def' } ), ] ) ------------------------------------------------------------------------ First, what d'you think? Too clunky and verbose? Too much information for each extension? I kind of think so, but I'm not sure how to reduce it elegantly. Right now, the internal data structures needed to compile a module are pretty obviously exposed: is this a good thing? Or should there be some more compact form for setup.py that will be expanded later into the full glory we see above? I've already made one small step towards reducing the amount of cruft by factoring 'include_dirs' out and supplying it directly as a parameter to 'setup()'. (But that needs code not in the CVS archive yet, so I've left the sample setup.py the same for now.) The next thing I'd like to do is get that damn "def_file" out of there. To support it in MSVCCompiler, there's already an ugly hack that unnecessarily affects both the UnixCCompiler and CCompiler classes, and I want to get rid of that. (I refer to passing the 'build_info' dictionary into the compiler classes, if you're familiar with the code -- that dictionary is part of the Distutils extension-building system, and should not propagate into the more general compiler classes.) But I don't want to give these weird "def file" things standing on the order of source files, object files, libraries, etc., because they seem to me to be a bizarre artifact of one particular compiler, rather than something present in a wide range of C/C++ compilers. Based on the NumPy model, it seems like there's a not-too-kludgy way to handle this problem. Namely: if building extension "foo": if file "foo.def" found in same directory as "foo.c" add "/def:foo.def" to MSVC command line this will of course require some platform-specific code in the build_ext command class, but I figured that was coming eventually, so why put it off? ;-) To make this hack work with NumPy, one change would be necessary: rename Src/numpy.def to Src/_numpy.def to match Src/_numpy.c, which implements the _numpy module. Would this be too much to ask of NumPy? (Paul?) What about other module distributions that support MSVC++ and thus ship with "def" files? Could they be made to accomodate this scheme? Thanks for your feedback -- 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

4 5

Can now compile simple extensions
by Greg Ward 29 Apr '18

29 Apr '18

Hi all -- at long last, I found the time to hack in the ability to compile extension modules to the Distutils. Mainly, this meant adding a 'build_ext' command which uses a CCompiler instance for all its dirty work. I also had to add a few methods to CCompiler (and, of course, UnixCCompiler) to make this work. And I added a new module, 'spawn', which takes care of running sub-programs more efficiently and robustly (no shell involved) than os.system. That's needed, obviously, so we can run the compiler! If you're in the mood for grubbing over raw source code, then get the latest from CVS or download a current snapshot. See http://www.python.org/sigs/distutils-sig/implementation.html for a link to the code snapshot. I'm still waiting for more subclasses of CCompiler to appear. At the very least, we're going to need MSVCCompiler to build extensions on Windows. Any takers? Also, someone who knows the Mac, and how to run compilers programmatically there, will have to figure out how to write a Mac-specific concrete CCompiler subclass. The spawn module also needs a bit of work to be portable. I suspect that _win32_spawn() (the intended analog to my _posix_spawn()) will be easy to implement, if it even needs to go in a separate function at all. It looks from the Python Library documentation for 1.5.2 that the os.spawnv() function is all we need, but it's a bit hard to figure out just what's needed. Windows wizards, please take a look at the 'spawn()' function and see if you can make it work on Windows. As for actually compiling extensions: well, if you can figure out the build_ext command, go ahead and give it a whirl. It's a bit cryptic right now, since there's no documentation and no example setup.py. (I have a working example at home, but it's not available online.) If you feel up to it, though, see if you can read the code and figure out what's going on. I'm just hoping *I'll* be able to figure out what's going on when I get back from the O'Reilly conference next week... ;-) Enjoy -- 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

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

Re: [Distutils] distutils install probs on suse 9.0
by Phillip J. Eby 01 Jun '04

01 Jun '04

At 10:22 AM 5/19/04 +0200, Floris van der Tak wrote: >Distutils was indeed part of python-devel, which is on the dvd, >but is not part of the standard installation. > >Thanks for your help, Floris Somebody should probably provide feedback to the packager that they shouldn't yank out arbitrary parts of the Python distribution into separate (OS-level) packages. The standard library is the standard library: it should not be subdivided.

4 5

Get your hands on the leading software products at only a fraction of the costs! ; -) monic
by Tamika Flores 31 May '04

31 May '04

1 0

VIRUS IN YOUR MAIL
by postmaster＠mailsrv.aviointeriors.it 31 May '04

31 May '04

V I R U S A L E R T Our viruschecker found the I-Worm.NetSky.r virus(es) in your email to the following recipient(s): -> catfor(a)aviointeriors.it Please check your system for viruses, or ask your system administrator to do so. For your reference, here are the headers from your email: ------------------------- BEGIN HEADERS ----------------------------- Received: from aviointeriors.it (adsl110.12.cyb.it [195.191.12.110]) by mailsrv.aviointeriors.it (Postfix) with ESMTP id 958C6C8404 for <catfor(a)aviointeriors.it>; Mon, 31 May 2004 17:05:57 +0200 (CEST) From: distutils-sig(a)python.org To: catfor(a)aviointeriors.it Subject: Mail Delivery failure (catfor(a)aviointeriors.it) Date: Mon, 31 May 2004 17:28:57 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_001B_01C0CA81.7B015D10" X-Priority: 1 X-MSMail-Priority: High Message-Id: <20040531150557.958C6C8404(a)mailsrv.aviointeriors.it> -------------------------- END HEADERS ------------------------------

1 0

G*A*Y FUC-k-K ONLY! fin affine isochronal apocalypse portulaca simulcast electron solicitude diphtheria cummings harbinger einstein rockefeller volt citrus yak berlin iridium distaff wong ecosystem travertine miami adonis deliquescent proscription automate methacrylate bend elton glance gratis ethereal
by Support portulaca 30 May '04

30 May '04

- --- - FUKK ME GAYY - - -- -- FIRST G*A*Y FUC-k-K ONLY! http://www.fuckmegay.com/indexnem.html?k[7

1 0

Huge savings on OEM Software. All brand names available now conceptual
by Amanda Gardner 28 May '04

28 May '04

1 0

better job
by Gretchen Barrera 27 May '04

27 May '04

1 0

Re: Question
by pgsql-general＠postgresql.org 24 May '04

24 May '04

I have corrected your document.

1 0

Message ("The distribution of your message dated Sun, 23...")
by L-Soft list server＠IEEE Computer Society (1.8e) 23 May '04

23 May '04

The distribution of your message dated Sun, 23 May 2004 12:02:51 +0200 with subject "Re: Your picture" has been postponed because the AWARDS list is held. No action is required from you; your message will be reprocessed automatically once the list owner releases the list.

1 0

bring a professional look to your projects
by wanglinxia＠sina100.com 21 May '04

21 May '04

We make Xp icons for commercinal manufacturers. If you are a software developer, webmaster or user interface designer looking for high quality icons and glyphs for your software projects. You have come to the right place. Here you can browse and buy high quality royalty-free icon. Our icons collections will bring a professional look to your projects while saveing your time and money. Browse icons collection URL: http://www.guiicons.com Best Greeting The guiicons.com team

1 0

Results of your commands
by SYMPA 21 May '04

21 May '04

> another pic, have fun! ... :-> Command not understood: ignoring end of message. No command found in message

1 0

does that position require a university degree? We'll sell you a REAL one!
by Merrill Hartley 20 May '04

20 May '04

1 0

Re: [Distutils] thoughts on distutils 1 & 2 (addendum)
by has 20 May '04

20 May '04

Hey, Couple more thoughts to add to yesterday's: - Decoupling DU build procedures from DU installation procedures also implies delegating control of building and installing to separate scripts (e.g. 'build.py', 'install.py'), rather than having a single 'setup.py' script doing double duty. Superficially this may sound like it's creating more(!) work for module developers, but bear in mind my goal of making these scripts more generic so that in most cases the module developer can simply [re]use existing ones rather than have to code new versions each time. - Regarding the "human-readable flag" aspect of setup.py, as this does cause some concern... In an _ideal_ world, the absence of a setup.py script would simply indicate that a module could be installed via a generic installation process. This _not_ being an ideal world, however (i.e. non-DU-compatible modules also lack a setup.py script, making it hard to tell the two forms apart), there's no reason a standard 'install.py' script couldn't always be included. Also, removing metadata from setup scripts means that most of the time 'install.py' will be a completely generic script that can be automatically added to the .zip at build-time; one less thing for the module developer to have to do themselves. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/

3 6

Re: [Distutils] thoughts on distutils 1 & 2
by has 19 May '04

19 May '04

Hi all, Sorry for slow reply; was a bit unwell over weekend. Will attempt a point-by-point response per topic later if feeling brave <g> (yipe! lots of replies). Meantime, here's a more general response to some of the areas of discussion/concern that I've picked up on so far: - Regarding standard package managers on *nix systems (which I've not used): does DU intend to wrap these, or plug into them? Current impression is it's the former; in which case, what's the reasoning for this? I'd have thought it'd make more sense for a system's native package manager to "be in charge", as it were, with DU only acting under their control. BTW, I've no objection to folks using package managers that want to use them; equally, I don't believe folks should _have_ to use them (e.g. because runaway complexity or rampant lock-in makes any other approach impossible). DU should be able to scale up as far as the user wants; but it shouldn't start "high up". Nothing's worse than systems that bury themselves (and their users!) under the weight of their own complexity. - Regarding target layout: I realise it's not DU's position to _dictate_ layout to systems. What I'm thinking is the packaging scheme should be 1. simple, 2. standardised, 3. self-contained, 4. a good 'default' layout. Distributing every Python module/extension as a Python package (aside from eliminating the confusion over what "package" actually means, since the word is currently used to mean two different things) would allow DU to invert the current distribution format and thereby eliminate a level of folder nesting (simpler) and provide a more convenient 'all-in-one' format to kick around on a typical system without losing anything (self-contained). Folk who are happy with that layout (e.g. would the average Mac/Windows user want/need to break the package up?) need do nothing more (good 'default' layout). Folk on *nix systems who want to move the 'doc' folder to /usr/share/doc/ are free to do so (though copying or symlinking it might be better), and, given a standardised layout, a generic installer script could easily perform that operation. (Ironically, I don't think it's the system's position to _dictate_ layout to users either... but arguing with *nix's OCD tendencies is, I suppose, ultimately fruitless; it is what it is. [Roll on relational file systems...:p]) - Regarding "integration": there are good and bad ways to integrate systems. Examples of good: small, distributed, single-task components linkable via unix pipes, Apple events, etc. Examples of bad: vast, centralised (Soviet bloc-style), "do-it-all" frameworks full of wrapper classes round every other system imaginable and more kitchen sinks than you can count; inevitably end up riddled with ultra-tight coupling, dependencies up the wazoo, and for all the supposed "power" never quite manage to do what you want (inflexible). (e.g. See Python web framework arena for examples of latter.) - On splitting various roles of setup.py into individual scripts (/src/build.py, /doc/build.py, etc.): aim isn't directly to simplify things for developer/user. It's to decouple each functional unit of DU, and establish small, simple, open, "generic" interfaces between them. This will make each DU component easier for DU developers to work on, and easier for DU users to "plug-n-play" with. e.g. DU has a good extension building component that could and should stand on its own (it may even find uses outside of DU itself), and be easily replaceable with alternative build components (based on makefiles, scons, etc.); this "ext_build" component would simply become "one of the boys" - a peer to all the others, rather than their master (with all the additional responsibility and complexity that involves). Create "modest", not "Macbeth", code. - On setup.py providing a very useful indication that "this is a DU-installable package": good point; noted. Any system where setup.py wasn't ubiquitous would want to provide an equivalent "user-readable flag", as it were. (Standardised file+folder structure, presence of standard metadata and readme files, etc.) - Regarding manifests: stupid, brain-dead, error-prone, anal-retentive, make-work garbage. These _should_ be eliminated. This will do two things: 1. allow a very simple, sensible "default" package building behaviour to be instituted (i.e. zip the entire folder by default); 2. allow for more intelligent customisation of package building behaviour by DU users, who should be able to give "smart" instructions like "build package including every item whose extension is not in ["pyc", "so"]", instead of having to provide and tediously maintain a "dumb" list of filenames. - On metadata formats: don't really care what format is used as long as it is simple, human-readable and -writeable, easily machine-parseable, and sufficiently powerful to represent package metadata. (e.g. Not sure if standard Mime-like format used for PKG-INFO is up to the task: can it do nested structures and lists? Format I suggested can do this, and is simple enough that its 'non-standardness' should not present any problems for adoption.) Oh, and a standard meta.txt file in every package means PKG-INFO can also be gotten rid of (it's nowt but a weak, clumsy bit of duplicated data anyway). - On PEP262 elimination: again, if users want to create and maintain their own database of installed packages using existing package manager tools then that's their choice. What's important is that this should not be the "default" arrangement, for reasons I've already given (synchronisation issues, etc.). By putting metadata into every Python package in the filesystem and building an API for retrieving that data directly from those packages, you have a solid "lowest-common-denominator" foundation that can also meet the majority of users' needs for no additional effort. For folk who like to maintain a separate DB for efficiency (e.g. on NFS), it also provides them the means to easily build that DB given an existing installation, not to mention an easy way to rebuild it after it goes blooey! - Basically, goals are: power thru flexibility; flexibility thru simplicity; simplicity thru decentralisation. Have simple, sensible, effortless defaults (though don't prevent user customising these). Decouple different functional areas. Increase genericity. Play nice with others (i.e. should cooperate with them, not boss them around). Normalise metadata structures and format. Thoughts? Regards, has p.s. If anyone can point me to good examples of DU-based binary distributions, I'd like to take a look to help my understanding, thanks. -- http://freespace.virgin.net/hamish.sanderson/

2 1

RE: Strong and weak points of distutils 1 Was: [Distutils] thoughtson distutils 1 & 2
by Moore, Paul 18 May '04

18 May '04

From: Mark W. Alexander [mailto:slash@dotnetslash.net] > In my view of the perfect world, the OS tools would deal with > dependencies based on the metadata provided by the binary packages. [...] > Since Windows does not provide that ability natively, then Distutils > need not try to extend Windows to include it. That (including the trimmed bit) sounds exactly right to me. > This is why I believe the core value of Distutils is the simple > management of package metadata. Building, installing or making binary > packages are all actions based on the supplied metadata. How the > result is integrated into any particular platform should be as native > as possible for each platform. Exactly. And (IMHO) that is the key strength of the bdist_wininst command - it fits in with the existing Windows infrastructure (limited though that may be). I've no experience with distutils on non-Windows platforms, but I'd instinctively look for a platform-native bdist option (bdist_rpm, bdist_dpkg, whatever). Even if I have a pure Python package, I always go via bdist_wininst and an OS-level install. I *never* do python setup.py install. Just because of the OS integration. (And this is from someone with an instinctive mistrust of installers, due to long experience with buggy Windows installers for other packages!) (On Windows, it may be worth adding a bdist_msi command, to use the MS installer infrastructure, but I don't personally know if that adds enough value to justify the work involved. I'm not familiar enough with the MSI format). Paul. __________________________________________________________________________ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. __________________________________________________________________________

1 0

Receive big discounts on MS Win 2000, XP, Office, Adobe, Corel products from Todd's Stuff Store
by Sonya Pina 18 May '04

18 May '04

1 0

Have a nice day! //the righteousness of Jesus Christ, therefore man is justified
by Cheerios P. Epitomizing 17 May '04

17 May '04

Get easy money! http://members.lycos.co.uk/lancer131/1/ --- when the temptation comes again with power, he is carried

1 0

RE: Strong and weak points of distutils 1 Was: [Distutils] thoughtson distutils 1 & 2
by Moore, Paul 17 May '04

17 May '04

From: Ronald Oussoren > On 15-mei-04, at 0:23, Lars Immisch wrote: >> From Bob: >> >>> Not all operating systems have a usable package management system >>> (Win32, Mac OS X, probably others). >> >> What's wrong with Installer.app and/or PackageMaker? > Both are installers, not package management systems. There is no public > interface for listing which packages are installed and uninstalling > packages, let alone dependency management. Hmm. I'm not sure I see what you're saying here. If you're saying that a "usable package management system" needs to support a "public interface" for listing which packages are installed, uninstalling packages, and dependency management (which you'd need to define more clearly) then Windows certainly does have one (albeit a bit primitive). Applications which wish to participate in the standard "Add/Remove Programs" interface have to register certain registry keys, so to some extent that would count as a "public interface". Listing & uninstall only, there's no dependency management, but it's a start. And it's what the current bdist_wininst uses, so it's supported by distutils right now. What, specifically, do you need the OS to provide, and why? What real problem exists with the current system? (At least in the context of the "build a standard OS package" commands, like bdist_wininst, bdist_rpm, etc). The only major issue I see is dependency management, and, personally, I'm happy to treat this as a documentation issue (package X documents that it relies on package Y, version a.b or later, and package Z, version c.d). Of course, I don't want automatic downloading of dependencies, uninstalling of dependencies when a package is uninstalled, etc, which maybe others do... Paul. __________________________________________________________________________ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. __________________________________________________________________________

3 2

thoughts on distutils 1 & 2
by has 17 May '04

17 May '04

Hello List, Very quiet here, so thought I would toss in some notes I've been making regarding Python's module system, the current DistUtils 1.x and some of the proposals I've seen for Distutils 2. These notes are very rough so I dunno how much sense they'll make to anyone else in their current state, but I figure it's better to pitch them in to find out if there's any interest in discussing them further than spend time polishing them if there isn't. Let us know what you think, and we can take it from there if folk are interested. Regards, has ------- Issues: http://www.python.org/cgi-bin/moinmoin/DistUtils20 states: "The ultimate goal: Must be backwards-compatible with existing setup.py scripts." This is both a red herring and likely recipe for DU2 becoming a big ball of mud before it's even out the door... - Compatibility for existing setup.py scripts can easily be ensured by retaining DU1. DU1 should be declared at end of its development life. DU1 API may eventually be re-implemented on top of DU2, allowing DU1 core to be ditched to reduce maintenance cost. Deprecate DU1 API. - DU1 doesn't scale down as well as it could/should. Doesn't scale up as well as it could/should. Current DU2 proposals don't seem to address these points, seeking only to add new material on top rather than reexamine/reevaluate existing architecture. Some current DU2 proposals smack of rampant architecture astronomy, lacking sufficient evaluation of their potential cost or whether the same goals could be achieved through other, simpler means. - DU2 provides an opportunity to review everything learnt over course of DU1 development and do it better. DU1 development has stagnated under its own weight. DU1 architecture is a rat's nest. Not a good base to build DU2 on. Better to design afresh: assemble list representative range of use cases and their relative frequencies in real-world use, determine "ideal" solution, determine "practical" solution. "Practical" solution = "ideal" solution minus anything that would prove too disruptive to Python, or too expensive for the benefits it'd provide, or where existing material from DU1 could be leveraged in at less cost than reimplementing from scratch. ------- Recommend: - Before adding new features/complexity, refactor current _design_ to simplify it as much as possible. Philosophy here is much more hands-off than DU1; less is more; power and flexibility through simplicity: make others (filesystem, generic tools, etc.) do as much of the work as possible; don't create dependencies. -- e.g. c.f. Typical OS X application installation procedure (mount disk image and copy single application package to Applications folder; no special tools/actions required) versus typical Windows installation procedure (run InstallShield to put lots of bits into various locations, update Registry, etc.) or typical Unix installation procedure (build everything from source, then move into location). Avoiding overreliance on rigid semi-complex procedures will allow DU2 to scale down very well and provide more flexibility in how it scales up. - Eliminate DU1's "Swiss Army" tendencies. Separate the build, install and register procedures for higher cohesion and lower coupling. This will make it much easier to refactor design of each in turn. - Every Python module should be distributed, managed and used as a single folder containing ALL resources relating to that module: sub-modules, extensions, documentation (bundled, generated, etc.), tests, examples, etc. (Note: this can be done without affecting backwards-compatibility, which is important.) Similar idea to OS X's package scheme, where all resources for [e.g.] an application are bundled in a single folder, but less formal (no need to hide package contents from user). - Question: is there any reason why modules should not be installable via simple drag-n-drop (GUI) or mv (CLI)? A standard policy of "the package IS the module" (see above) would allow a good chunk of both existing and proposed DU "features" to be gotten rid of completely without any loss of "functionality", greatly simplifying both build and install procedures. --Replace current system where user must explicitly state what they want included with one where user need only state what they want excluded. Simpler and less error-prone; fits better with user expectations (meeting the most common requirement should require least amount of work, ideally none). Manifest system would no longer be needed (good riddance). Most distributions could be created simply by zipping/tar.gzipping the module folder and all its contents, minus any .pyc and [for source-only extension distributions] .so files. -- In particular, removing most DU involvment from build procedures would allow developers to use their own development/build systems much more easily. - Installation and compilation should be separate procedures. Python already compiles .py files to .pyc on demand; is there any reason why .c/.so files couldn't be treated the same? Have a standard 'src' folder containing source files, and have Python's module mechanism look in/for that as part of its search operation when looking for a missing module; c.f. Python's automatic rebuilding of .pyc files from .py files when former isn't found. (Q. How would this folder's contents need to be represented to Python?) - What else may setup.py scripts do apart from install modules (2) and build extensions (3)? -- Most packages should not require a setup.py script to install. Users can, of course, employ their own generic shell script/executable to [e.g.] unzip downloaded packages and mv them to their site-packages folder. -- Extensions distributed as source will presumably require some kind of setup script in 'src' folder. Would this need to be a dedicated Python script or would something like a standard makefile be sufficient? -- Build operations should be handled by separate dedicated scripts when necessary. Most packages should only require a generic shell script/executable to zip up package folder and its entire contents (minus .pyc and, optionally, .so files). - Remove metadata from setup.py and modules. All metadata should appear in a single location: meta.txt file included in every package folder. Use a single metadata scheme in simple structured nested machine-readable plaintext format (modified Trove); example: ------------------------------------------------------------------ Name roundup Version 0.1.0 Intended Audience End Users/Desktop Developers System Administrators License OSI Approved Python Software Foundation License Topic Communications Email Office/Business Software Development Bug Tracking Dependencies etc... ------------------------------------------------------------------ - Improve version control. Junk current "operators" scheme (=, <, >, >=, <=) as both unnecessarily complex and inadequate (i.e. stating module X requires module Y (>= 1.0) is useless in practice as it's impossible to predict _future_ compatibility). Metadata should support 'Backwards Compatibility' (optional) value indicating earliest version of the module that current version is backwards-compatible with. Dependencies list should declare name and version of each required package (specifically, the version used as package was developed and released). Version control system can then use both values to determine compatibility. Example: if module X is at v1.0 and is backwards-compatible to v0.5, then if module Y lists module X v0.8 as a dependency then X 1.0 will be deemed acceptable, whereas if module Z lists X 0.4.5 as a dependency then X 1.0 will be deemed unacceptable and system should start looking for an older version of X. - Make it easier to have multiple installed versions of a module. Ideally this would require including both name and version in each module name so that multiple modules may coexist in same site-packages folder. Note that this naming scheme would require alterations to Python's module import mechanism and would not be directly compatible with older Python versions (users could still use modules with older Pythons, but would need to strip version from module name when installing). - Reject PEP 262 (installed packages database). Complex, fragile, duplication of information, single point of failure reminiscent of Windows Registry. Exploit the filesystem instead - any info a separate db system would provide should already be available from each module's metadata. -- http://freespace.virgin.net/hamish.sanderson/

7 10

didn't go to college - that's ok we'll give you a diploma
by Williams Yoder 16 May '04

16 May '04

1 0

no need to lie on your application, we can sell you a verifiable university degree
by Rolland Steele 15 May '04

15 May '04

1 0

Re: did I send this to you?
by Jose Travis 14 May '04

14 May '04

1 0

Detected as SPAM: TEST
by Dominique Unruh SpamDetector 12 May '04

12 May '04

Your message has accidentially been classified as SPAM. It therefore has been deleted. To bypass the SPAM filter, please send a new message containing the string DNIQ_THIS_IS_NO_SPAM in body or subject. Yours, Dominique Unruh.

1 0

Your message to Trasno awaits moderator approval
by trasno-bounces＠ceu.fi.udc.es 08 May '04

08 May '04

Your mail to 'Trasno' with the subject Mail Delivery (failure trasno(a)ceu.fi.udc.es) Is being held until the list moderator can review it for approval. The reason it is being held: SpamAssassin identified this message as possible spam Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://ceu.fi.udc.es/cgi-bin/mailman/confirm/trasno/858040b84d3e14912b92802…

1 0

7- your opinion is valuable
by Nelson Hayes 07 May '04

07 May '04

1 0

Your message to xml awaits moderator approval
by xml-admin＠gnome.org 06 May '04

06 May '04

Your mail to 'xml' with the subject Re: Re: Thanks! Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision.

1 0

Your message to xslt awaits moderator approval
by xslt-admin＠gnome.org 06 May '04

06 May '04

Your mail to 'xslt' with the subject Re: Your text Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision.

1 0

Your message to xml awaits moderator approval
by xml-admin＠gnome.org 05 May '04

05 May '04

Your mail to 'xml' with the subject Re: Sex pictures Is being held until the list moderator can review it for approval. The reason it is being held: SpamAssassin thinks there may be spam in this message. Either the message will get posted to the list, or you will receive notification of the moderator's decision.

1 0

Out of Office AutoReply: Thank you for delivery
by Jimmy Lindh 04 May '04

04 May '04

Hej, jag har slutat på Spray Network Services Min e-mailadress är tills vidare jimmy(a)spraylabs.net mvh --jimmy

1 0

problem with setup.py
by Flavio Codeco Coelho 04 May '04

04 May '04

Hi, I am trying to get my first setup.py to work and I have written the following setup.py. It's for a pure python application. # -*- coding:iso8859-1 -*- from distutils.core import setup setup(name = 'ModelBuilder', version = '0.2.2', description = 'ODE model builder and simulator', author = 'Flávio Codeço Coelho', author_email = 'fccoelho(a)fiocruz.br', url = 'http://www.procc.fiocruz.br/~cursos/course/view.php?id=6', download_url = 'http://savannah.nongnu.org/projects.modelbuilder', scripts = ["PyMB"], py_modules = ["PyMB","wxFrame1","wxFrame2","about","uncertaintyMiniFrame", 'PlotFigure'], data_files = [('bitmaps',['backup_section.png','mathematics_section.png','graphics_section.png', 'spreadsheet_section.png','timemanagement_section.png']),('models',['3eqs.ode','HH.ode', 'pk.ode','pk_unc.spec']), ('doc',['README','COPYING']),('html',['ModelBuilder_About.html'])], classifiers = [ 'Development Status :: 4 - Beta', 'Environment :: X11 Applications', 'Intended Audience :: End Users/Desktop', 'License :: GPL2', 'Operating System :: Unix', 'Programming Language :: Python', 'Topic :: Scientific/Engineering :: Mathematics', ], ) I also wrote a MANIFEST.in to make sure all the files got included in the source distribution, and it works fine to create a source tarball. The problem is that when I try to run python setup.py install it gives the following error message. error: file 'PyMB' does not exist What am I missing? Flávio Codeço Coelho, PhD Programa de Computação Científica Fundação Oswaldo Cruz Rio de Janeiro -- Brasil ________________________________________________________________________

2 2

(BRMA) Alerta 01: Virus encontrado - Entrada
by BRmultiaccess＠belco.com.br 04 May '04

04 May '04

Alerta 01: Virus encontrado - Entrada ---------------------------------------- Virus Encontrado no email de entrada ---------------------------------------- Para: financasne(a)belco.com.br Assunto: Mail Delivery (failure financasne(a)belco.com.br)

1 0

Msvccompiler.py
by Ivan R. Judson 03 May '04

03 May '04

Interesting problem: sometimes you want to build extensions with a newer version of the compiler than the python interpreter was built with. Sometimes you want to be smarter than the machine, so it would be very handy to have some manual override in msvccompiler.py, in get_build_version(), perhaps something like: if os.environ.has_key('MSVC_VERSION'): return float(os.environ['MSVC_VERSION']) This allows you as the smart developer to force the compilation of the extension to use whatever compiler version you set your environment to; if you don't set it, the system does what it does now. Thoughts? -Ivan

2 2

Encrypted document
by python-list＠cwi.nl 01 May '04

01 May '04

1 0