[Distutils] Pre-pre-PEP: Requirements for the Python BUILDS Specification

[Josselin Mouette]

Le mardi 07 octobre 2008 à 16:51 -0400, Phillip J. Eby a écrit :
> >If you write a tool to do that, why not make it simply move files
> >properly and let the code locate them, instead of adding yet another
> >layer on top of the existing stuff? The tool will not be more
> >complicated this way.
> 
> I'm not sure I follow you.  What I'm proposing is that:
> 
> 1. A BUILDS "manifest" for a project should list the files included 
> in the project by what "kind" of file they are, as well as by 
> inter-file relationships (e.g., "these 3 files are part of Python 
> package 'foo.bar' within this project, and they are static data used 
> at runtime but not read or written").
> 
> 2. BUILDS-compatible install tools will be free to install those 
> files wherever they like (or create .debs, .rpms, etc. that do), and 
> use symlinks so that the installed project can find them in the 
> places that the developer wanted to find them.
> 
> Is this what you're asking for?  Because it's what I've been trying 
> to say we should do.

What I am afraid of is that, by adding just another layer, you will
introduce new problems while fixing existing ones. Currently we already
have a hard time maintaining a symlink farm, and adding a second symlink
farm on top of it is not going to make things more understandable
(currently, package maintainers already have a hard time understanding
how to deal with Python modules) nor more reliable.

The first kind of issues I can think of is that dpkg handles symlinks to
directories very badly, so you’re likely to run into issues that have to
be dealt with by hand by maintainers. I haven’t thought about it much,
but I have the feeling that other things will break.

In the end, if you are designing a new packaging specification and a new
tool, I think you’d better take this as an occasion to do the right
thing instead of adding this new layer.

> For example, if Debian needs metadata that's not in the core BUILDS 
> metadata, it should be possible within BUILDS to include it, so that 
> it can be contributed upstream.  Likewise, it should be possible for 
> a BUILDS install tool to use a third-party supplement to get that 
> data, so that when you're initially porting a project, you could 
> write a file with the additional data while doing the initial port, 
> then submit that file upstream.

If there is a need for Debian-specific metadata, it will go in the
debian/ directory. It looks interesting to integrate it upstream only if
it is relevant for other distributors.

> Less flippantly, our goal here is to have something that has a better 
> cost/benefit ratio for adoption by a Python developer who has not 
> seen any pressing need for autoconf in their life to date.  And if 
> somebody wants to make a BUILDS tool to generate autoconf sources 
> from a project manifest, then great!

No, no. Please don’t :)
But if you can express in the project manifest the same flexibility as
with autoconf (or even the tenth of it, we don’t need *that* much
flexibility), that should be enough.

> >BTW, I would consider it a good approach to try bringing BUILDS on par
> >with the autotools capabilities. These tools have serious drawbacks, but
> >they were written with the ability to work for distributors in mind.
> 
> Sure.  I like stealing designs and requirements definition from 
> mature projects, even if you might argue that I chose poor role 
> models for setuptools.  (Java and OSGi.)
> 
> However, since autotools compatibility isn't a goal in itself, I 
> think I'll leave it to those people who have interest/experience to 
> propose what specific autotools features they'd like to see in 
> BUILDS, and the use cases they have for them.  If I were to just skim 
> the docs trying to figure that out, I might think that something cool 
> in it is actually useful, or vice versa.  ;-)  So, it's better here I 
> think to hear from experienced users such as yourself.

There is no use in being compatible with the autotools, the point is
about stealing good ideas.

The first thing that comes to mind, and that we already discussed at
large, is the ability to specify at install time where data,
documentation, manual pages and so on have to go.


Another thing that I consider a good design (when expunged of the
useless stuff in it) is the config.h file. It is a file that is
generated at configure time and which contains macros you may need
inside your code: package version, installation directories, enabled
features, etc.

What some Python projects using autoconf are doing, and I’d like to see
in BUILDS, is the generation of a config.py file at installation time.
It would be useful to specify install-time stuff like installation
directories, optional features and installation parameters.

For example it could contain:
        version = "1.2.3"
        builddate = "Tue 7 Oct 2008, 23:12 +0100"
        templates_dir = "/usr/share/foobar/templates"
        has_libamazing = True # _foobar.so is built with libamazing support
        page_footer = "Powered by foobar"

For Python-only packages, you can easily ship a default config.py file
that works without installation:
        version = get_version_from_changelog ()
        templates_dir =
        os.path.join(os.path.basedir(__file__),"templates")
        page_footer = "Foobar (development version)"

By doing such a thing, you are guaranteed to obtain easily the data you
need from within the Python application:
        import config
        template = file(os.path.join(config.templates_dir),
        "foo.template")

I may be biased because I’m used to work like this, but I find this
easier for both the developer and the distributor. In my personal
experience, it is also more reliable.


Another thing from the autotools that I’d like to see is seamless
integration with pkg-config, for modules with C extensions. Bonus points
for being able to use not only compilation flags and installation paths,
but also macros you need to use inside the code (they could go in
config.py).

I’ll tell you if I can think of other things.

Cheers,
-- 
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081008/07524467/attachment.pgp>