[Distutils] stdeb-0.3 error

Gerry Reno greno at verizon.net
Thu Sep 24 01:23:57 CEST 2009

Andrew Straw wrote:
>>>>> OK, based on your code I added a "bdist_deb" distutils command to
>>>>> stdeb.
>>>>> I've checked this into the old-stable branch and I'd appreciate it if
>>>>> you can check whether this works for you and send me any comments.
>>>>> Invoke it like this:
>>>>> python -c "import stdeb; excecfile('setup.py')" bdist_deb
>>>> See this was my point of why my 'bdist_deb' belonged as a distutils
>>>> patch and not in stdeb.
>>>> The inherited capabilities, behaviors and invocation style needs to
>>>> follow all the other 'bdist' command types.
>>>> And that means being able to invoke it the same as say 'bdist_rpm'
>>>> like:
>>>> python setup.py bdist_deb
>>>> or
>>>> python setup.py bdist_deb --<std bdist type arg> ...
>>>> If we start allowing 'bdist' derivative commands to diverge in their
>>>> inherited capabilities, invocation style, and expected behaviors then
>>>> chaos will ensue.
>>> This does have the same invocation style -- if you change your setup.py
>>> to import stdeb. Otherwise, it's still the same invocation style -- you
>>> just have to import stdeb outside the setup.py file.
>>> Also, this version of bdist_deb is never going to make it into the
>>> standard library as it depends on stdeb.
>>> So feel free to make a counter proposal, but I'm inclined to think this
>>> is useful to people as-is and has the benefit of working today.
>> My view is this.  The 'bdist' family of commands should be reserved
>> for pure Distutils implementations not dependent upon setuptools or
>> stdeb.  Putting a command to create the .deb based on my code into
>> stdeb is fine but that command should not be a 'bdist_xxx' command. 
>> It should be somthing like bstdeb_deb so that a true 'bdist_deb' can
>> still be developed for Distutils and not be in conflict with some
>> other 'bdist_deb' out there.
> 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.
My only concern is that namespaces are important and if we end up with 
two solution paths that each use the same namespace then this becomes 
very confusing for users.  Yes, I understand that if you don't import 
stdeb in your setup.py then you can use a 'bdist_deb' from Distutils.

>> At some point, the 'bdist' family of commands should evolve into
>> OS-specific varieties.  And this means that for example, redhat,
>> fedora, mandriva, or any other rpm-package distro would have their own
>> 'bdist_DISTRO' command that would inherit from 'bdist_rpm' and then
>> institute their own rules/policies onto a generic 'bdist_rpm'.  And
>> the same would hold true for example a 'bdist_ubuntu' command that
>> would inherit from a 'bdist_deb' command or in general for any
>> 'bdist_DISTRO' command that would inherit from a 'bdist_PACKAGETOOL'
>> command.
> I don't see what's so specific about ubuntu versus debian right now that
> there's any reason for a different set of commands for the two.
> Therefore, I think this is a red herring w.r.t. the present discussion.
For ubuntu, at the moment at least, that's true.  But distros like 
redhat are creating their own rules/policies around rpm naming 
conventions, build options, etc. and of course they should be able to do 
this and I expect other distros will do the same, and these will diverge 
more over time even though they will all use the same packaging tool 

>> Maybe we can get some overall guidance here from Tarek who has been
>> coordinating a lot of these types of things. 
I think this is a good topic for someone with a long view about where 
things are headed here to weigh in on this.
I'm fine with whatever fits in with the longer term goals.


More information about the Distutils-SIG mailing list