Gerry Reno wrote:
Tarek Ziadé wrote:
2009/9/23 Andrew Straw <straw...@astraw.com>:
Well, it wouldn't be setting a precedent that importing a module would
extend the functionality of the stdlib's distutils commands -- the
setuptools and distribute projects already do this. For example, the
"sdist" command in setuptools has many differences with that of "sdist"
in plain distutils. The point is that a user can choose not to import
setuptools and thus not get the different behavior.

The case here is that if the stdlib ever grows bdist_deb, that's fine,
but I don't see why that should prevent stdeb from implementing a
bdist_deb command of its own. In this case, I think the issue is even
less relevant, since there is no stdlib "bdist_deb" command. Users would
naturally expect "bdist_deb" to do exactly what stdeb is implementing.
As long as I'm going ahead an implementing the functionality (which I'm
ambivalent about in and of itself for previously stated reasons), I
think it should be named the most obvious name.


During last Pycon summit, we v'e said that part of the problem with Distutils
was that it was doing too much things and that we should probably try to
remove all platform-specific commands to reduce its scope.

For instance, bdist_rpm is fine, but being located in Python stdlib, its release
cycle is too long, and it would probably be better for it to be on its own,
managed by people from the "rpm community" (if this term makes sense,
e.g. Fedora
guys maybe ?)

Same thing goes with bdist_deb : while it's more controversial to
remove existing bdist_*
command, we will not include new bdist_* commands for sure in Distutils,
and rather let the debian/ubuntu community provide the best packaging
solution on the top of Distutils.

That said, if stdeb provides a plain Distutils command, that doesn't
use Setuptools
and if that command is stable and used in the community, we will be happy to
add a pointer to it in Distutils documentation.

The problem of using Setuptools or Distribute in a command is that it
does a lot of patching
(much more that overriding distutils sdist command) and that changes
Distutils global
behavior. Notice that the Distribute project plans to remove that
patching in the future.

Notice also that Distutils has a plugin system, where you can point a
package that
contains extra commands. This configuration can be done in distutils.cfg.

This allows the usage of the command in the CLI without having to
import the command
directly in the setup.py file.

Last, about the name, I think using "bdist_deb" is fine imho. If
another project uses the same
name, it's juste a matter of configuring the one to be used in a given context.

Regards
Tarek
So are you saying then that a stddeb-based 'bdist_deb' should be implemented as a standalone plugin to Distribute? And how would that work for distros such as Ubuntu 8.0.4 Hardy? Would they be able to take advantage of Distribute?

I think a long term goal should be getting away from the plugin nature of distutils. I don't see why distutils (or my mythical distlib) shouldn't just be a package (or more likely multiple packages) that stand-alone tools can use. Other than much complexity and confusion, I don't see what plugins have bought us. Not everything (and especially not distutils) needs to be a framework.

I'll admit that this plan in years down the road, at best. And it's not anyone's official position.

Eric.
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Reply via email to