[Distutils] stdeb-0.3 error

[Andrew Straw]

>>>> 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.

> 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.

> Maybe we can get some overall guidance here from Tarek who has been
> coordinating a lot of these types of things. 

Sure. CCed.

-Andrew