Mailman 3 December 1999 - Distutils-SIG

Re: [Distutils] Disposition of C extensions and packages
by Michel Sanner Dec. 20, 1999

Dec. 20, 1999

On Dec 20, 5:29pm, Guido van Rossum wrote: > Subject: Re: [Distutils] Disposition of C extensions and packages > [Michael Sanner] > > What management are you talking about here ?? It seems to me that > > duplicate copies of identical files (one copy per platform) is > > inconvenient (at least for my perspective). > > Suppose a new version of a package is released for platform X but not > yet for platform Y (maybe platform Y is less popular and the only > maintainer is on vacation). Further suppose the platform-independent > files are changed in the new version. Now if you install it in the > shared area for platform X, you screw platform Y's installation. > Without a shared area, each platform can update without affecting the > others. > OK, you have a point there ! although this raises the issue of packages version support ! > > Moreover, why provide an prefix and an exec_prefix if we are going to put > > everything into the same tree anyway ?? > > They are old features; 5 years ago this was worth it to save 0.5 Mb of > disk space. > Does that mean that this will disapear ? it is it old stuff, it should ! Or do you think that the /sys.prefix/lib should remain shared ? While we're at it, maybe the extensions that are distributed along with the Python intertpreter should be re-evaluated. I have a hard time explaining why some extensions like the rotor module are part of the Python standard distribution while Numeric is not ! These might be details, but I am in the process of trying to convince people at SDSC (San Diego Suppercomputer Center) to support Python for their users and questions like these are raised ! -Michel -- ----------------------------------------------------------------------- >>>>>>>>>> AREA CODE CHANGE <<<<<<<<< we are now 858 !!!!!!! Michel F. Sanner Ph.D. The Scripps Research Institute Assistant Professor Department of Molecular Biology 10550 North Torrey Pines Road Tel. (858) 784-2341 La Jolla, CA 92037 Fax. (858) 784-2860 sanner(a)scripps.edu http://www.scripps.edu/sanner -----------------------------------------------------------------------

1 0

Re: [Distutils] Disposition of C extensions and packages
by Michel Sanner Dec. 20, 1999

Dec. 20, 1999

On Dec 20, 12:06am, M.-A. Lemburg wrote: > Subject: Re: [Distutils] Disposition of C extensions and packages > "A.M. Kuchling" wrote: > > > > Questions: > > > > 1) A general Python question about packaging style: Is mixing > > C extensions and Python modules in one package tree a bad > > idea? It makes the whole tree platform-dependent, which is > > probably annoying for sites maintaining Python installation > > for different architectures. > > I have been using that setup for two years now with all of > my mx extensions and so far it has been working great. > > If you maintain packages with C extensions for several > platforms, you can simply install the packages under > the platform subdirs in /usr/local/lib/python1.5 -- one > copy for every platform. Disk space is no argument anymore > nowadays. > Agreed, disk space is not an issue, but file duplication is not very nice. I think this is a real weakness in Python: on one hand we have platform independent extensions which are great on the other hand we have native extensions when performance is required. This is, at least for me (in scientific computing) what makes Python such a great tool, BUT Python does not provide a mechanism to split a single package into platform dependent and platform independent part. We maintain Python and a number of packages for IRIX, SunOS, Dec Alpha OSF, Win32 and linux ... and having to update 5 .py files at every bug fix is a real pain. -Michel -- ----------------------------------------------------------------------- >>>>>>>>>> AREA CODE CHANGE <<<<<<<<< we are now 858 !!!!!!! Michel F. Sanner Ph.D. The Scripps Research Institute Assistant Professor Department of Molecular Biology 10550 North Torrey Pines Road Tel. (858) 784-2341 La Jolla, CA 92037 Fax. (858) 784-2860 sanner(a)scripps.edu http://www.scripps.edu/sanner -----------------------------------------------------------------------

4 5

ANNOUNCE: Distutils 0.1.2 released
by Greg Ward Dec. 16, 1999

Dec. 16, 1999

Phew, just in time for Christmas. Get your copy today from http://www.python.org/sigs/distutils-sig/ Many bugs fixed in this one. Works great on Linux and Solaris; I didn't hear back from anyone about whether it works on Windows, so I'm taking a chance. Here's the entry from the CHANGES file: * changes to command-line semantics: - verbose mode is now the default - added help options (and generation of help text), both globally and for each command - better usage message * anywhere that accepts/requires a list of strings now also accepts a tuple of strings (but lists of tuples still have to be lists -- there are limits) * fixes to "build_py" command - explicitly ensure that the setup script (sys.argv[0]) is never included with the modules to be installed - do *not* preserve file mode when copying .py files into the build tree (was preserving 0444 permissions [read-only], which caused subsequent installation of the same module distribution to fail) - several silly bugs that showed up when building simple, non-packagized distributions * fixes to the "dist" command - correct behaviour with filename pattern regexes - don't blow up if MANIFEST missing, just warn and carry on - blow away "distribution" tree after making archive file(s) Enjoy! Thanks to everyone who spotted bugs (especially Guido for a very useful checklist). 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

6 9

Re: [Distutils] ANNOUNCE: Distutils 0.1.2 released
by Michel Sanner Dec. 16, 1999

Dec. 16, 1999

Greg, Your doing an excellent job ! don't worry about G Stein's comment ... he is not ALWAYS right ! and IMHO, I do not think that this word of caution in you mail was worth posting a message ! -Michel On Dec 16, 10:03am, Greg Ward wrote: > Subject: Re: [Distutils] ANNOUNCE: Distutils 0.1.2 released > On 15 December 1999, Greg Stein said: > > Who cares whether it is chancy or not? > > > > This is a symptom that I've seen from many people. "Oh! I can't release > > yet... it might break." Or another favorite "Here is a pre-release, please > > test it and then I'll make a real release." > > In my own defense, I think I like the code snapshot followed by a real > release a few days later. That shows the world that things are > happening, and gives me time to take care of the bureaucracy of making a > release: make sure everything's checked in and tagged, update the > changelog, update the readme, update the web pages, and so forth. > > Of course my self-imposed bureaucracy *does* slow down making releases > -- I would have a hard time putting out new versions every other day > because I insist on having a readable, grammatical, up-to-date README > file, and I am really keen on having everything under CVS control and > appropriately tagged. These are the little things that make trying out > new software a lot easier on people; I for one am sick to death of > moderately good software that is hobbled by a lousy, out-of-date README > or poorly-written documentation. I prefer to take a few hours more and > put out quality information as well as quality code. > > IOW, yes: release early and release often. But how early and how often > are matters of personal style, and not everyone can proceed at a > Linus-esque breakneck pace of new releases every couple of days. > > Greg > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG(a)python.org > http://www.python.org/mailman/listinfo/distutils-sig >-- End of excerpt from Greg Ward -- ----------------------------------------------------------------------- >>>>>>>>>> AREA CODE CHANGE <<<<<<<<< we are now 858 !!!!!!! Michel F. Sanner Ph.D. The Scripps Research Institute Assistant Professor Department of Molecular Biology 10550 North Torrey Pines Road Tel. (858) 784-2341 La Jolla, CA 92037 Fax. (858) 784-2860 sanner(a)scripps.edu http://www.scripps.edu/sanner -----------------------------------------------------------------------

1 0

One more small bugfix
by Greg Ward Dec. 13, 1999

Dec. 13, 1999

Hmmm, from the deafening silence, either a) everyone has tried out yesterday's snapshot and found it to be so utterly mundane and boring as to be unworthy of comment, or b) you were all waiting for today's snapshot, which fixes one teeny-weeny little bug. Anyways, get it from http://www.python.org/sigs/distutils-sig/implementation.html Unless someone finds a bug, I'll probably toss 0.1.2 over the wall tomorrow. Windows people, *please* try this snapshot out! (Especially Windows people with a compiler and the NumPy, PIL, or mxDateTime sources handy -- give one or all of the example setup scripts a whirl. They work for me under Linux...) Greg

1 0

Distutils 0.1.2 almost ready
by Greg Ward Dec. 12, 1999

Dec. 12, 1999

Hi folks -- I've finally gone on a bug-fixing spree to clean up all the easy problems in Distutils 0.1.1. The harder problems will have to wait for 0.2, but for now I'm going to release these fixes as 0.1.2. Before I do that, I've put out a code snapshot with all the fixes -- please download it and give it a try, especially if you reported problems with 0.1.1 or if you run Windows. You'll find the snapshot at: http://www.python.org/sigs/distutils-sig/implementation.html Thanks -- 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

1 0

Questions about distutils strategy
by Ian Searle Dec. 8, 1999

Dec. 8, 1999

We are developing a cross platform debug tool for embedded systems that uses Python as the central foundation. We distribute our product on both solaris and windows nt. Thus, distutils looked attractive for building our python extensions, which are mostly C++. This last weekend, I was working on an extension, and ended up punting distutils for two reasons: 1) the documentation is not adequate for a moron like me. I needed to add a vendor supplied object file to the link command, and struck out on every attempt. The doc gave me some clues, but was not specific enough to really help. I realize that this is version 0.1. 2) the main/compelling reason is that I have to debug the python extensions. The extension implementation is normally tested, and debugged prior to integration into Python. But the extension layer often needs some debugging as we are interfacing C++ with STL containers to Python data types. I can debug just fine using distutils on Solaris/Linux, but cannot do the same on Windows. As far as I can tell, you _have_ to have a DevStudio project setup to debug anything under windows. Since our product will be delivered as a standalone tool, including python, I do not need the distribution facilities of distutils, only the development. But, once I have developed a DevStudio project/workspace for an extension, there is little motivation to use distutils. I am hopeful that distutils will evolve into a useful development and distribution tool for python. Though, I wonder how the "debugging extensions on Windows" problem will be approached. Cheers, -Ian Searle

11 22

Re: [Distutils] Random bits
by Michael Hudson Dec. 7, 1999

Dec. 7, 1999

Greg Ward <gward(a)cnri.reston.va.us> wrote on Tue, Dec 7, 1999, 4:26 pm [snip] >[Michael again] >> Would it be reasonable to have an "interactive" mode, or am I just being >> silly again? > >Interesting notion. Would this just be a shell for the Distutils >commands, eg. > > ./setup.py --interactive > > build > [...output of 'build' command...] > > install > [...output of 'install' command...] > > quit > >or did you have something else in mind? More or less that; I was thinking of the script you get when you run CPAN for the first time - where you get asked lots of questions about where things are, and most of the time you just hit return a lot. Something more like this in outline: $ python setup.py --interactive > install * Installing some_dist... ** Building somedist ** Where do you want to build? [./build]> <return> ** output of build process * Where do you want to install the pure Python modules? [/usr/lib/python1.5/site-packages]> ~/src/python<return> * Where do you want to install extension modules? [/home/mwh21/src/python]> <return> * output of build process as I said, I'm not particularly convinced this is to be desired; it can certainly be added at a later date. Cheers, Michael

1 0

Random bits
by A.M. Kuchling Dec. 7, 1999

Dec. 7, 1999

Some things I came across while adding distutils support to some code: * From a docstring in distutils/versions.py: 0.4 0.4.0 (these two are equivalent) 0.4.1 Does this mean that 0.4.1 is equivalent to 0.41 in the strict versioning class? I'd suggest adding that, just to make it crystal clear. * The name option in setup.py: It's not clear if it can/should contain spaces; given that you mention underscores, I assume they're as space substitutes. * Building a distribution: it creates hard links to files. This means that if you delete a file and rebuild the dist without erasing the hard-link-filled subdir, the deleted file is still present in the distribution. It's probably easiest to blow away the whole <product>-<version> directory, rather than attempting to scan its contents and update it. -- A.M. Kuchling http://starship.python.net/crew/amk/ "I don't think we should interfere." "Interfere? Of course we should interfere! Always do what you're best at, that's what I say." -- Romana and the Doctor, in "Nightmare of Eden"

10 27

Re: [Distutils] Distutils integration
by Greg Stein Dec. 6, 1999

Dec. 6, 1999

On Mon, 29 Nov 1999, T-Methy Moddletin wrote: > Mon, 29 Nov 1999 08:57:02 -0500, Greg Ward <gward(a)cnri.reston.va.us> wrote: > >Cool... BUT I worry that having multiple Python archives or > >meta-archives might be as bad as having none at all. > > Ouch. (-: Ah well, since this is the state of things, at least we > may as well have a way to more conveniently search for what's out > there. Don't let Greg dissuade you. In almost all cases, something is better than nothing. The current state of a Python archive (or index) is pretty abysmal. Keep doing what you're doing! Don't stop! :-) >... > No, in my opinion (which may not be worth much) there is one thing at > least worse than having a meta-archive... and that's having > ftp.python.org/pub/python/contrib/ ! No offense ment to anyone! But > that place has become a terrible mess. And i hate README files! I'll second your opinion. It has been a LONG time since I bothered to look in there. I go to the web now for Python code. >... > Of course if there was a central archive, that takes care of finding > things as well (assuming everyone wants to bother with going to the > trouble of getting archived there). Still I must dissent. In > retrospect, I am not fond of CPAN. I do not miss it. I do not consider > it a model for emulation. It had perhaps some useful attributes----but > I am (and hopefully I don't just say this because it is the nature of > my-project-which-i-must-protect) genuinely in favour of > decentralised resources. I think it's more encouraging to people to > directly and easily control and release their stuff (and for those > who want to upload somewhere there is still ftp.python.org!) While > there are certain weaknesses and logistic complications (and yeah, > perhaps "mess" also!) it seems a much freer environment to me. Less > stuffy, as it were. Less official! Perhaps my biases are showing a > little too strongly. I find the rigidity of CPAN just a little too > intimidating, in fact. I argued the same topic (different approach, tho) on the trove-dev mailing list (archives at www.python.org/pipermail/trove-dev). Basically, I believe the current Internet user is looking for a Freshmeat-style index, rather than a sunsite-style repository. Repositories are passe, indexes are The Right And Just Way. :-) Anybody can get a web page and some disk space. Therefore, anybody can publish their code themselves -- there is no need for central repositories except to help out lazy people that won't publish thru a web page. (alright, maybe that's too strong, but I'm making a point here :-) The problem, of course, is finding all this stuff. IMO, you ought to look harder at the Freshmeat style of index. More of the work is pushed onto the author, rather than the site maintainer. The editors review each announcement or edit, but I don't think they personally clean up the database. (yes, I realize some of your efforts are due to "startup" rather than a plan to do ongoing maintenance) >... > Already i note these quibles in the last few messages about version > number parsing. When creating the Vaults of Parnassus database I had I posted a little version number parser about a year ago, I think. It handles most forms of version numbers, returning a tuple that can be properly ordered (among the software's other releases using that version number pattern). If you need to parse version numbers, that's the function to use. Cheers, -g -- Greg Stein, http://www.lyra.org/

3 2