[Distutils] stdeb-0.3 error

[Gerry Reno]

Andrew Straw wrote:
> Gerry Reno wrote:
>   
>> Andrew Straw wrote:
>>     
>>> I saw your patch, but that wasn't what I meant. Disabling
>>> --single-version-externally-managed has to be optional, and the argument
>>> must continue to be used by default. Simply removing the call will
>>> create a regression for namespace packages. Thus, the
>>> --single-version-externally-managed should only be removed when someone
>>> explicitly asks for it to be removed (because they presumably know what
>>> they're doing or are at least aware it may have negative consequences).
>>> Hence my suggestion to look at how the --ignore-install-requires works
>>> as an example of how to pass an option via the distuils infrastructure.
>>>
>>>   
>>>       
>> I'll look at --ignore-install-requires and send another patch.
>>     
> OK, great.
>
>   
>>> 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.

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.

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


Regards,
Gerry