[Distutils] bdist_deb in stdeb

[Gerry Reno]

Andrew Straw wrote:
> Gerry Reno wrote:
>> Andrew Straw wrote:
>>> Gerry Reno wrote:
>>>  
>>>> Olof Bjarnason wrote:
>>>>    
>>>>>  
>>>>>      
>>>>>> Ok, the commands behave like makefile rules, once run they don't run
>>>>>> again.
>>>>>> But there are still several issues here:
>>>>>>
>>>>>> Remember that I said that my goal with 'bdist_deb' was for users to
>>>>>> have a
>>>>>> SINGLE command to generate a .deb.
>>>>>>
>>>>>> What needs to be achieved is for a command like this:
>>>>>> $ python setup.py  bdist_deb
>>>>>> OR
>>>>>> $ python setup.py  bdist_deb
>>>>>> --ignore-single-version-externally-managed
>>>>>>
>>>>>> to be possible.  'bdist_deb' would call sdist_dsc internally with the
>>>>>> necessary args WITHOUT having to explicitly put 'sdist_dsc' on the
>>>>>> command
>>>>>> line.
>>>>>>             
>>>>> This would be _exactly_ what I'm looking for :)
>>>>>         
>>>> I know.  I've had many of my users requesting exactly the same thing
>>>> as well and I've been pursuing this for months now and when I got a
>>>> 'bdist_deb' working with stdeb I knew I was getting close.  It just
>>>> needs a little more tweeking and I think we'll have it.  Let's wait
>>>> and see what Andrew says here.
>>>>     
>>> I don't understand what you're waiting on me for at this point.
>>>
>>> Olaf -- as I understand it -- you need to work with Ubuntu 9.04. I just
>>> released stdeb 0.4 which supports this "bdist_deb" and doesn't pass the
>>> --single-version-externally-managed option anyway and therefore doesn't
>>> support the "--ignore-single-version-externally-managed" option. I don't
>>> understand why you need to pass
>>> "--ignore-single-version-externally-managed". "python setup.py
>>> bdist_deb" should work for you. Please report with specific information
>>> about expected and actual behavior if things are not working to your
>>> desire (taking care to read the, admittedly minimal, documentation in
>>> README.rst).
>>>
>>> Gerry -- I don't understand why you want to subvert the normal distutils
>>> way of doing things. Passing arguments to bdist_deb that are really
>>> arguments to sdist_dsc just isn't the way distutils does things. 
>> Please explain this then.  Why EVEN bother to call 'sdist_dsc' from
>> within 'bdist_deb' if you cannot somehow pass arguments to the
>> internal 'sdist_dsc' call?
> You can. "python setup.py commandA --option-for-command-A commandB
> --option-for-command-B". This is just how distutils works. This is not
> an stdeb issue. If you don't need to pass options to commandA, but
> commandA is still a sub-command of commandB, then commandA will still
> get called, just without any options. As I said, you can also pass
> options by placing them in the appropriate setup.cfg location.
>
> For example:
>
> python setup.py build_py --build-lib=zzz bdist_dumb
>
> is exactly equivalent to
>
> python setup.py bdist_dumb
>
> with if setup.cfg file contains:
>
> [build_py]
> build-lib=zzz
>
> Because build_py A) is a sub-command of bdist_dumb and therefore gets
> run and B) picks up its options using the standard distutils mechanisms,
> either from the command line or setup.cfg.

YES, I UNDERSTAND THE MECHANISM.
What if stdeb only had the command 'bdist_deb' and had no other 
command.  Everything else was taken care of internally.  What then?  Are 
you saying then that it is impossible to pass in any options to 
'bdist_deb' to affect the generation of the source package?  If true, 
this makes NO SENSE.




>
>>
>>> You're
>>> asking for the equivalent of being able to pass arguments to the
>>> distutils install command that are ultimately intended for the distutils
>>> build_ext command. If you want to test (and possibly implement)
>>> functionality such as adding a [sdist_dsc] section to setup.cfg where
>>> these options could just live so that you don't need to pass arguments
>>> at the command line, thats would be welcome.
>>>
>>> Gerry, point 2 -- I still think you're not looking at your own big
>>> picture here -- AFAIK, you are bending over backwards to attempt to pass
>>> the "--ignore-single-version-externally-managed" so that you don't have
>>> to import setuptools in your setup.py file to avoid the monkeypatching
>>> that setuptools does. 
>> Stop. NO.  IF I import stdeb in the setup.py THEN any local distutils
>> install class gets an error:
>> --single-version-externally-managed not recognized (or something
>> similar).
> So why don't you just derive from setuptools' install command (rather
> than distutils' install command) if you insist on using stdeb 0.3? I
> think this will solve all your problems in a much simpler way.
Yes, I can see that once we got invaded with setuptools it seems you 
really have no other choice.



>
>> The only way to get by this is by passing in the NEW option that I
>> made, '--ignore-single-version-externally-managed' which removes this
>> option from the install command which then allows the install to
>> succeed.   This is because it looks like stdeb hijacks the distutils
>> install command.
>
> I have yet to see a working patch that I can actually test that backs up
> your assertion. As it is, I simply don't believe you because the
> debian/rules created by stdeb 0.3 not only passes that option, but it
> also explicitly imports setuptools. The setuptools install command does
> know the --single-version-externally-managed option. (I think in your
> memory of what worked, you are forgetting that you also removed the
> "import setuptools".)
>
> -Andrew
>

And getting back to the issue that got skipped:
Another issue:  In util.py on line 962 (gerry-reno git):
%(setup_env_vars)spython$* -c "import 
setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})" 
install \\

Maybe it should be like this (note semicolon splitting line into two 
statements):
%(setup_env_vars)s;    python$* -c "import 
setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})" 
install \\

Otherwise any of the env vars don't seem to be in effect for the  line 
itself.   If you put any of the env vars in the line, they don't expand 
to the value set in set_env_vars.  They expand to previous value or to 
null.



Regards,
Gerry