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.
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