Differences between revisions 3 and 18 (spanning 15 versions)
Revision 3 as of 2004-03-19 17:34:49
Size: 1891
Comment:
Revision 18 as of 2008-11-15 14:00:57
Size: 5171
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Distuils BoF Topics = = Followup =
Line 3: Line 3:
There have been many proposals for changes and improvements to distutils,
but any actual activity on improving distutils appears to have come to a
There will be a follow-up Open Space meeting on Friday at 11:30 am.

Someone should volunteer to act as a scribe for the meeting.

= 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
Line 6: Line 12:
on top of distutils. on top of `distutils`.
Line 9: Line 15:
directly into distutils itself, with the most important being shared directly into `distutils` itself, with the most important being shared
Line 12: Line 18:
incorporating distutils extensions directly into their distributions. incorporating `distutils` extensions directly into their distributions.
Line 14: Line 20:
but seems out of place for smaller distributions of a single pakcage
(like ZConfig).
but seems out of place for smaller distributions of a single package
(like `ZConfig`).
Line 20: Line 26:
- Support for installing both modules and packages from a single distribution.  * Support for installing both modules and packages from a single distribution.
Line 22: Line 28:
- Support for more easily installing data files into a package. Phillip Eby's setuptools has implemented one reasonable approach to this; there may be others.  * Support for more easily installing data files into a package. Phillip Eby's `setuptools` has implemented one reasonable approach to this; there may be others.
Line 24: Line 30:
- The ability to install packages into other packages without having to hack around in setup.py scripts. (For example, the option to install zope.app.sqlscripts into an existing installation of zope.app.)  * The ability to install packages into other packages without having to hack around in ''setup.py'' scripts. (For example, the option to install `zope.app.sqlscripts` into an existing installation of `zope.app`.)
Line 26: Line 32:
- Some ability to use more declarative forms of metadata from setup.py without having to write a pile of extension code. This is being explored some at Zope Corporation.  * Some ability to use more declarative forms of metadata from ''setup.py'' without having to write a pile of extension code. This is being explored some at Zope Corporation.
Line 28: Line 34:
- Dependency support. This is also being worked on by Phillip Eby, but it would be nice to get more information from the community about the requirements.  * Dependency support. This is also being worked on by Phillip Eby, but it would be nice to get more information from the community about the requirements.
Line 30: Line 36:
If any distutils-related sprints emerge, hopefully there can be a progress
report from that; it is not yet clear that there will be a distutils sprint.
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)
Line 35: Line 48:
[mailto:fdrake@acm.org FredDrake], Andrew Kuchling. The following people showed up for the first hour of the BOF; once we'd
overrun our time in room 308, a much smaller subset of this group relocated
to the amphitheatre to continue discussions.

 * [[mailto:fdrake@acm.org|FredDrake]]
 * Andrew Kuchling
 * BobIppolito
 * Zac Bir
 * Mike Orr
 * Yannick Loitiere
 * Tamer Fahmy
 * Nathan Yergler
 * Anna Ravenscroft
 * Eric Smith
 * Brian Dorsey
 * Kevin Cole
 * David Handy
 * John Miller
 * Barry Warsaw
 * Lloyd Kvan
 * Paul Prescod
 * David Ascher
 * Trent Mick
 * Pearu Peterson
 * Nester Nissen
 * Tom Cocagne
 * Michael Cariaso
 * Eric Jones
 * Steve Waterbury

This was a much larger group than expected from the initial response in this
wiki; I'll apologize for not organizing more of an agenda.

= General Review =

Discussion quickly led to Fred realizing that people characterize distutils in
two very different ways. Many people talked about distutils as a build framework,
and others see it as a packaging system/tool. Both aspects are important to
have available, but they are not equally important to everyone. Someone with
time on their hands should consider more clearly separating the two aspects so
that either can be used separately; this is perhaps of more concern to people
who want to use distutils as a build system.

One proposal was to either use [[http://www.scons.org/|SCons]] as a foundation for
the build component, or to factor out a common base set of functionality.


'''''(There's more to say here; please add it if you can, since I'll probably forget it before I get around to writing about it here.)'''''

Followup

There will be a follow-up Open Space meeting on Friday at 11:30 am.

Someone should volunteer to act as a scribe for the meeting.

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:

  • Support for installing both modules and packages from a single distribution.
  • Support for more easily installing data files into a package. Phillip Eby's setuptools has implemented one reasonable approach to this; there may be others.

  • The ability to install packages into other packages without having to hack around in setup.py scripts. (For example, the option to install zope.app.sqlscripts into an existing installation of zope.app.)

  • Some ability to use more declarative forms of metadata from setup.py without having to write a pile of extension code. This is being explored some at Zope Corporation.

  • Dependency support. This is also being worked on by Phillip Eby, but it would be nice to get more information from the community about the requirements.

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)

Attendees

The following people showed up for the first hour of the BOF; once we'd overrun our time in room 308, a much smaller subset of this group relocated to the amphitheatre to continue discussions.

  • FredDrake

  • Andrew Kuchling
  • BobIppolito

  • Zac Bir
  • Mike Orr
  • Yannick Loitiere
  • Tamer Fahmy
  • Nathan Yergler
  • Anna Ravenscroft
  • Eric Smith
  • Brian Dorsey
  • Kevin Cole
  • David Handy
  • John Miller
  • Barry Warsaw
  • Lloyd Kvan
  • Paul Prescod
  • David Ascher
  • Trent Mick
  • Pearu Peterson
  • Nester Nissen
  • Tom Cocagne
  • Michael Cariaso
  • Eric Jones
  • Steve Waterbury

This was a much larger group than expected from the initial response in this wiki; I'll apologize for not organizing more of an agenda.

General Review

Discussion quickly led to Fred realizing that people characterize distutils in two very different ways. Many people talked about distutils as a build framework, and others see it as a packaging system/tool. Both aspects are important to have available, but they are not equally important to everyone. Someone with time on their hands should consider more clearly separating the two aspects so that either can be used separately; this is perhaps of more concern to people who want to use distutils as a build system.

One proposal was to either use SCons as a foundation for the build component, or to factor out a common base set of functionality.

(There's more to say here; please add it if you can, since I'll probably forget it before I get around to writing about it here.)

DistutilsBof (last edited 2008-11-15 14:00:57 by localhost)

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