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

[Josselin Mouette]

Le mardi 07 octobre 2008 à 19:25 -0400, Phillip J. Eby a écrit :
> At 12:43 AM 10/8/2008 +0200, Josselin Mouette wrote:
> >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.
> 
> I guess I'm confused a bit here, since the idea is not to have 
> maintainers need to understand anything but how to be able to tell 
> upstream, "hey, you didn't configure file X correctly".  At least, 
> that's what I'd hope would be all that's needed.  :-)

First, it is wrong to expect maintainers to not understand what they do.
It is a guaranteed recipe for failure.

Second, it is not realistic to assume that all the maintainer will do is
forward bugs to the upstream developers, and that upstream developers
will fix it in the minute – especially for packaging issues, which
developers generally disregard. The maintainer often needs to patch the
sources or the installation scripts so that the software installs
properly, and to do so he needs to understand what he does.

> >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.
> 
> Actually, until I saw the Twisted plugins directory use case, I 
> hadn't actually seen any use cases for symlinks to directories that 
> couldn't be handled by using a directory of symlinks instead.  Are 
> there any other Python packages you know of that would need a symlink 
> to a directory?

Yes, you can arrange for not meeting this specific issue. What I’m
saying is not that such issues don’t have workarounds, I’m saying that
we will discover new ones, again and again, as long as the only thing we
do to fix each issue is add another carpet to hide the dust.

> The idea of the BUILDS "install locations" (IL) manifest is just that 
> it lists the contents of the project distribution, and describes the 
> logical locations that things go in.  So, part of the BUILDS spec 
> would be what categories exist for the above.

If the only thing it does is allowing to move files and symlink them, I
frankly doubt the benefits will outperform the cost of maintaining this
new symlink farm.

> >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.
> 
> It looks like a great idea, and I'm all for recommending people use 
> it, or something like it.  I'm also fine with BUILDS having support 
> for some sort of "install-time editing" like this.  I just don't want 
> it to be a requirement that everybody change their ways.  Not 
> everybody even uses pkg_resources' API for accessing data files yet, after all.

You don’t have to make it a requirement. If you agree with the idea of
such a feature, a good approach might be to:
      * always generate this file;
      * provide the possibility to easily install it;
      * let developers gradually start using it directly in the code.

> >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).
> 
> Sorry, what is pkg-config?

pkg-config is becoming the de-facto standard for providing information
about installed development libraries. With it you can easily:
      * obtain compile-time parameters for dependent programs (CFLAGS
        and LIBS);
      * require a range of versions for a number of libraries you depend
        on;
      * obtain any parameter that the developer wanted you to know (for
        example, the name of a dbus service you need to start, the path
        to a helper utility, or the installation path for plugins);
      * with the automake integration, enable programs or features based
        on the availability of dependencies.

For a Python example: you want to know where to install your definition
files for GNOME Python bindings? Just use:
	pkg-config --variable=codegendir pygtk-2.0

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/9c9d958d/attachment.pgp>