Revision 11 as of 2004-03-25 00:19:08

Clear message

Distutils BoF Topics

There have been many proposals for changes and improvements to distutils, but any actual activity on improving distutils appears to have come to a complete halt. All activity has moved to third-party tools which layer on top of distutils.

There is a case to be made for integrating the best of the enhancements directly into distutils itself, with the most important being shared maintenance and making the tools readily available for use by smaller distributions. Currently, many larger distributions of Python code are incorporating distutils extensions directly into their distributions. This isn't much of a problem for large distributions (like Zope and PEAK), but seems out of place for smaller distributions of a single package (like ZConfig).

The extensions which we should consider adding directly to distutils include:

Anthony Baxter, FredDrake, BobIppolito, and Kapil added a very simple dependency mechanism on Monday; we can discuss what was done and whether it's sufficient.

(Guys: you might have a look at setuptools.depends and setuptools.command.depends in the sandbox, as the dependency mechanisms there are more fleshed out (including unit tests), although they are not as smoothly integrated with distutils (e.g., I don't have a "skip" option for dependency checking yet). In particular, note that using import as a dependency checking mechanism will fail when installing to a directory not on the current PYTHONPATH; setuptools' dependency checking can handle this correctly, even in the presence of 'extra_path'. Also, I'm awfully YAGNI on provides in general. What are the use cases? --PJE)

['provides' is to allow packages to specify _what_ they provide. We can't use the name of the package, as often it's different (e.g. Twisted vs twisted). The next step will be to submit these provides lines to PyPI, so we can look them up. The 'import' hack is just there because we don't have the installation database yet - this can be removed at that point. -- anthony]

(But what's the use case for packages specifying what they provide? If I rely on Twisted, why not just say I rely on Twisted? What's the point of having another entity? Also, how does the installation database help with existing distributions, and packages that someone installed *before* the database exists? That approach will have backwards-compatibility problems in deployment for an extended period, while an explicitly backwards-compatible approach could work *now*. -- PJE)


Unable to edit the page? See the FrontPage for instructions.