[Distutils] thoughts on distutils 1 & 2

[Ronald Oussoren]

On 14-mei-04, at 22:25, has wrote:

> [Deep breath, everyone; it's gonna get longer before it gets 
> shorter...;]
>
> Stefan Seefeld wrote:
>
>> Example: compilation of extension modules.
>>
>> Scons is aiming at providing an abstraction layer for portable 
>> compilation.
>> DU2 should at least allow to just delegate compilation of extension 
>> modules to scons.
>> (and as I said previously, I think anything that doesn't allow to
>> wrap traditional build systems based on 'make' and possibly the 
>> autotools
>> is 'not good enough' in as a general solution).
>
> I'm far from expert on build systems (interpreted language weenie), 
> but do think it makes sense for DU to hand off compilation duties to a 
> third-party as quickly as it can. That third-party might be a separate 
> Python-based system, or makefile, or anything else; however DU 
> shouldn't need to know this.

DU should know about it, it should be easier to itegratie DU with other 
build systems but DU should still know about building extensions.

For this reason I also don't like your idea of splitting of various 
tasks into seperate python scripts, that doesn't really solve anything, 
e.g. why is writing a script named test.py *inherently* easier than 
writing a test action for distutils.

What's needed is an easier way to write and adapt DU actions, and to 
get tool-builders to include DU-actions/subactions with their tools. 
Pyrex already includes an build_ext action that will convert .pyx file 
to C, SWIG could do the same, as could docutils, unittest frameworks, 
...

BTW. what I like about distutils is that it provides an easy to 
recognize standard interface for installing python libraries. When I 
download a new python library and it includes a setup.py script I'm a 
happy camper, because I can install using 'python setup.py install' 
(*). When there's no setup.py script I've to read installation 
instructions, and often have to do various manual steps before I can 
install.

(*) In theory of course, in practice C extensions often need help to 
tell them where libraries are and which features are available in those 
libraries. I guess DU needs autoconf-like functionality for detecting 
features of (C-) libraries.

>
>
>>> - 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.
>>
>> Again, I don't think it is DU2's role to impose anything concerning
>> the target layout. This is often platform dependent anyways.

<nod>

I do like the idea of having a standard location for documetation and 
examples though.

A prefered source layout would also help (e.g. if you don't specify 
anything at all distutils could assume everything inside 'Lib' is a 
python module, everything in 'Doc' is documentation and the unittests 
are in 'Testsuite').

>
> Not quite sure if we're talking on same wavelength here. Let me try to 
> clarify my previous point first, then maybe you can explain yours to 
> me (feel free to phrase it in terms even an idiot like me can 
> understand; I won't be offended;).

Linux systems often have standard locations for placing documenation 
(such as /usr/share/doc/<package-name>), and likewise for other unix 
systems. If Python would place it's documentation elsewhere users would 
get confused.

>
> I'm talking of how a module/package gets put in a suitable Python 
> directory (e.g. site-packages), which I'm assuming (unless proven 
> otherwise) only requires that one knows which directory to put it in 
> and moving the module/package to it. I'm also assuming that DU should 
> not need to rearrange the contents of that package folder when 
> installing it (except perhaps in special cases where it must install 
> one of several platform-specific versions of a file, say; but that'll 
> be the exception rather than the rule, and packages that don't require 
> such special handling shouldn't need to go through the same in-depth 
> procedures to install).

You seem to be muddying the definition of a package. There's a python 
package as a specific language construct and there's python package as 
"a distribution of a python library", which are seperate entities. 
Merging them is IMHO confusing.

With little effort every python library could be placed into it's own 
subdirectory in site-packages:
	
	.../site-packages/
			MyPackage.pth
			MyPackage/
				module1.py
				package1/
					__init__.py
					module2.py

If the 'extra_path' argument of setup() were to be required we'd have a 
directory to that can be used to store additional information, and it 
would make d&d package management easier for those who like that.

Ronald
--
X|support bv            http://www.xsupport.nl/
T:  +31 610271479       F:  +31 204416173