Mailman 3 January 2001 - Distutils-SIG

Distutils and iconv codec
by Martin v. Loewis 11 Jan '01

11 Jan '01

It appears that there was a patch for processing -L options in distutils lately, see http://sourceforge.net/patch/?func=detailpatch&patch_id=102971&group_id=5470 so python setup.py build_ext -L/tmp -lbla works now for me. Unfortunately, passing -R is still broken; python setup.py build_ext -L/tmp -R/tmp -lbla gives ... File "/usr/local/lib/python2.0/distutils/unixccompiler.py", line 208, in link (libraries, library_dirs, runtime_library_dirs) = \ File "/usr/local/lib/python2.0/distutils/ccompiler.py", line 438, in _fix_lib_args runtime_library_dirs = (list (runtime_library_dirs) + TypeError: can only concatenate list (not "string") to list Also, I wonder what the rationale is for supporting -L/tmp:/var/tmp, while not supporting the Unixish -L/tmp -L/var/tmp. Regards, Martin

1 0

Re: [Distutils] Multi-distribution distributions
by Paul Prescod 09 Jan '01

09 Jan '01

"Mark W. Alexander" wrote: > > ... So to > implement sub-package support, each individual bdist_* module > has to be visited. Where you say "sub-package" I think you mean what I call "distribution unit" or "component". > The relevance here is that the bdist_generic class would > have built-in sub-package support which would then be > inherited to all (capable) package managers. I agree that some stuff could be abstracted into a base class but I still think that every bdist has to be touched to implement embedded distribution units. For instance Windows EXE would probably have to uncompress the embedded executables to a temporary directory, recursively execute them and then delete them. RPM would have to do something similar in a Unix-y way. Paul Prescod

1 0

Multi-distribution distributions
by Paul Prescod 09 Jan '01

09 Jan '01

I'm somewhat surprised by the fact that some distributions (e.g. Numpy, Zodb) have multiple setup.py programs. As far as I know, these setup.py's do not share information so there is no way to do a bdist_wininst or bdist_rpm that builds a single distribution for these multiple sub-packages. I see this as a fairly large problem! The bdist_ functions are an important part of Distutils functionality. Paul Prescod

5 12

Windows installer.
by Michel Van den Bergh 09 Jan '01

09 Jan '01

Hello, I have been looking at the windows installer coming with distutils. It seems fine for installing python extensions but not for what I would call "python applications" e.g. a games. For the end user the fact that an application is written in python is basically irrelevant (except that python needs to be installed to run it). An application will typically be installed in "C:\Program Files". Furthermore the user will expect a desktop shortcut, a start menu entry and an uninstall program. The current windows installer does not seem to be capable of installing, let alone generating such things. I noticed that there exists a free (as in free speech) installer for Windows: http://www.nullsoft.com/free/nsis/ which seems to be very capable. So it would be sensible to have an option "bdist_nsis" and I am considering writing such a thing. What do you think? Or is there something flawed in what I say? Regards, Michel

3 5

Re: [Distutils] How are patches processed?
by Jack Jansen 09 Jan '01

09 Jan '01

Recently, Andrew Kuchling <akuchlin(a)mems-exchange.org> said: > What are the current critical issues that need to be fixed in > Distutils? Well, I'd really like the Mac fixes for distutils to be in the repository before the 2.1a release... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

3 2

Windows installer.
by Michel Van den Bergh 09 Jan '01

09 Jan '01

> > > An application will typically be installed in "C:\Program Files". > > Furthermore the user will expect a desktop shortcut, a start menu > > entry and an uninstall program. The current windows installer does not > > seem to be capable of installing, let alone generating such things. > > I have come up with the same conclusion for Narval > (http://www.logilab.org/narval -- I know, this is a shameless plug ;o) > > > I noticed that there exists a free (as in free speech) installer for > > Windows: http://www.nullsoft.com/free/nsis/ which seems to be very > > capable. So it would be sensible to have an option "bdist_nsis" and I am > > considering writing such a thing. > > I have not looked at this installer. What we use at Logilab is Inno Setup, > which comes with an open source license too (it sounds BSD-ish, but > I'm not a license expert). It is very easy to use, and does a good work. > The URL is http://www.jrsoftware.org/isinfo.htm > > Alexandre Fayolle > -- > http://www.logilab.com > Narval is the first software agent available as free software (GPL). > LOGILAB, Paris (France). > I looked at Inno Setup. It is indeed very good and it comes with a BSD style licence. I was able to create a professional looking installer in 10 minutes. It seems very easy to create the installation script automatically by modifying bdist_dump a little bit. bdist_dump basically does a mock install to the build directory and then packs the result. Instead of packing the result one should make an installation script listing the files which were created by the mock install. Then Inno setup should be invoked. Bdist_inno could have a few options such as the name of the licence file, the name of the readme file, the name of the main script (to create shortcuts on the Desktop and in the Start Menu), the default install location and the path of the executable for the Inno setup application. When I find some time I will look into this. Thanks for the tip. Michel

2 1

RE: [Distutils] Proposal: Meta extensions (components)
by Mike Fletcher 08 Jan '01

08 Jan '01

This sounds a great deal like the Distribution Unit in the Open Software Description (http://www.w3.org/TR/NOTE-OSD.html). Might we want to adapt rather than reinvent such a thing? Bonus for Paul: it's XML! ;o) Enjoy yourselves, Mike -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Monday, January 08, 2001 7:05 AM To: Paul Prescod Cc: distutils-sig(a)python.org Subject: Re: [Distutils] Proposal: Meta extensions (components) Paul Prescod wrote: > > Andrew Kuchling wrote: ... > Let's start with terminology: there is a "missing term" in our > vocabulary. People sometimes use the words "module", "extension" and > "package" for a "distutils unit" but those words already have precise > meanings in the Python world. I propose the term "distutils component". > A distutils component consists of a directory which contains a setup.py > and some other code. The component is also the unit of versioning. > > Some components "embed" other components. The parent component is > dependent on the embedded component and for convenience, the embedded > component is distributed with the parent. Embedding may go away when > distutils has proper dependency tracking -- but it may not. > > It should be possible to create a "parent component" or "meta component" > by specifying the paths to sub-components. Just as you specify > "py_modules", "extensions" and so forth, you should be able to specify > "sub_components". Then distutils itself would do all of the "for > subcomponent in subcomponents: run_setup()" hackery that NumPy, ZODB, > etc. do "by hand" today. > > This could map into installers too. There is probably a way to create > RPMs that contain RPMs, windows EXEs that contain windows EXEs and so > forth. ...

1 0

How are patches processed?
by Jack Jansen 06 Jan '01

06 Jan '01

How are patches to the distutils code processed, and who can do this? I sent in a batch of fixes to make distutils work on the mac about 2 months ago, first to Greg personally and when he didn't react to the whole mailing list, but absolutely nothing seems to happen. I assume Greg is away or something, as he also doesn't post to the list, but I would think there are more people who have write-access to the repository, no? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

3 2

Re: [Distutils] How are patches processed?
by Jack Jansen 05 Jan '01

05 Jan '01

> I have asked that question before on python-dev... Greg seems to > be offline or way to busy (like many of us) to respond to questions. > > As for the repository: distutils is part of Python 2.0 CVS tree, so > Python developers should be able to commit changes to the distutils > tree too. I'd rather have Greg's OK for this first, though, since > he owns the code. This is indeed the problem I'm running against: Greg requested that changes go via him, but he's been away for ages now, which essentially stops distutils development dead. I was hoping that Greg had appointed at least one other person to decide on patches in his absence. Maybe we should ask him to do this when he surfaces again... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Creating Shared Extensions with Cygwin DLL Python and Distutils
by Jason Tishler 04 Jan '01

04 Jan '01

Cygwin DLL Python and Distutils work very well together to create shared extensions. Note that these extensions will only work with Cygwin DLL Python. They will not work with Win32 Python or Cygwin Python. However, this combination should facilitate UNIX shared extension providers with the porting of their modules to Windows. Cygwin DLL Python is a version of Cygwin Python with its core built as a DLL similar to Win32 Python. One can easy build Cygwin DLL Python by using the patches and instructions found at: http://cygwin.com/ml/cygwin/2000-11/msg00471.html and http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 for Python 2.0 and Python CVS, respectively. For a simple example see the first attachment. This is the setup.py that corresponds to the Demo/extend example found in the standard Python distribution. For a more realistic example see the second attachment. This is the setup.py that builds the python-ldap module: http://sourceforge.net/projects/python-ldap For the above to build, configure must have already been run and the attached patch (i.e., third attachment) applied. Note that this patch is just the same one necessary for the traditional Makefile.pre.in style build under Cygwin. Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corporation Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler(a)dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com

1 0