[Distutils] stdeb-0.3 error

[Gerry Reno]

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

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


Regards,
Gerry