[Distutils] bdist_deb in stdeb

[Olof Bjarnason]

OK I'm sorry for starting some kind of "battle" here :)

I guess "sdist_*" stands for "source distribution", and likewise
"bdist_*" stands for "binary distribution"?

Tell a rookie like me: what is a binary distribution of a python
application? It feels like an awkward concept.


2009/9/29 Gerry Reno <greno at verizon.net>:
> Andrew Straw wrote:
>>
>> Gerry Reno wrote:
>>
>>>
>>> Andrew Straw wrote:
>>>
>>>>
>>>> Gerry Reno wrote:
>>>>
>>>>>
>>>>> What if stdeb only had the command 'bdist_deb' and had no other
>>>>> command.
>>>>>
>>>>
>>>> I will not remove the "sdist_dsc" command from stdeb. I believe that the
>>>> ability to produce debian source packages is much more important that
>>>> the ability to produce binary packages which only target a single
>>>> architecture and version of Debian/Ubuntu. "bdist_deb" is just a trivial
>>>> add-on to that saving a couple lines of typing which may be helpful to
>>>> people who aren't familiar with those lines. But I see the .dsc and
>>>> associated files as much more useful as the compiled .deb files.
>>>>
>>>>
>>>>
>>>
>>> LMAO.  Dang it.  I am not suggesting or implying that you should
>>> remove the 'sdist_dsc' command.  I'm trying to illustrate that the
>>> commandA-opts are just that and nothing more: commandA-opts.  And
>>> whatever part of the build/install process that they apply to, then
>>> the commandA can use them for WHATEVER purpose.  Which means that
>>> since 'bdist_deb' calls 'sdist_dsc' it is perfectly ok to allow all
>>> 'sdist_dsc' options to be passed into the 'bdist_deb' command which
>>> can then pass them along to 'sdist_dsc'.  'bdist_deb' is a SUPERSET of
>>> 'sdist_dsc'.
>>>
>>
>> I see -- you want to pass-through the options to sdist_dsc. Fine,
>> implement this in a patch and I'll accept it.
>>
>
> Oh sure, I get to have all the fun.
>
>
>>
>>
>>>>
>>>> For setting environment variables this way, they cannot be separated by
>>>> a semicolon
>>>>
>>>
>>> The environment variables are not individually separated by a
>>> semicolon.  The WHOLE shell script environment variable declaration
>>> statement needs to be separated from the install line statement.
>>>
>>> Simple demonstration of the problem with the 'echo' statement
>>> simulating the 'install' statement:
>>> $ a='123' b='456' echo test $a $b
>>> test
>>> $ a='123' b='456'; echo test $a $b
>>> test 123 456
>>>
>>
>> Passing to a subprocess is different. We're passing to a subprocess:
>>
>> $ a='123' python -c "import os; print os.environ['a']"
>> 123
>> $ a='123'; python -c "import os; print os.environ['a']"
>> Traceback (most recent call last):
>>  File "<string>", line 1, in <module>
>>  File "/usr/lib/python2.6/UserDict.py", line 22, in __getitem__
>>    raise KeyError(key)
>> KeyError: 'a'
>>
>
> Ok, I see what is happening.  In order for the env vars to be available to
> both the line itself AND to the subprocess it has to be declared as exported
> like this:
>
> export a='123' b='456'; python -c "import os; print os.environ['a']" && echo
> $b
> 123
> 456
>
>
> Now it will work both ways.
>
> Regards,
> Gerry
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english