[Distutils] stdeb-0.3 error

Eric Smith eric at trueblade.com
Thu Sep 24 18:50:13 CEST 2009


Gerry Reno wrote:
> Tarek Ziadé wrote:
>> 2009/9/23 Andrew Straw <strawman at 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.


More information about the Distutils-SIG mailing list