[Distutils] bdist_deb in stdeb

[Andrew Straw]

Gerry Reno wrote:
> Andrew Straw wrote:
>> Gerry Reno wrote:
>>> I have attached a replacement 'bdist_deb.py' file that permits passing
>>> arguments to bdist_deb which in turn passes them down to sdist_dsc.
>>>
>>> and a util.py diff (made against the gerry-reno git branch) makes the
>>> setup_env_vars work for both the line statements as well as the
>>> subprocesses.
>> OK, I committed these to the old-stable branch and merged in the
>> bdist_deb changes to the master branch. I made some minor changes to
>> your option to disable --single-version..., the most significant of
>> which is the name, which is now "--disable..." instead of "--ignore...".
>> The other is that I'm not using env vars in the debian/rules file -- it
>> just clutters it up unnecessarily.
> Even so, it would still be more flexible if you leave in the 'export'
> statement.
More flexible, true -- but at a cost complexity and with no known use of
the flexibility. The complexity is that the auto-generated debian/rules
files are even less readable than they currently are in the old-stable
branch.

> That allows you to use the env vars in both the line AND the
> subprocess.  I know you're not using them right now, but at least
> later people would have the option if they wanted.
> And since you refactored the SVEM option you should make sure that
> there is at least ONE env var for the export statement and that can be
> anything, such as export HOME PATH DUMMY, etc. It's not absolutely
> critical but 'export' with no options will print all the exported env
> vars which might look strange in the log/output.

If you want to pass environment variables to your setup.py script, the
current method works fine. If one needs to modify the auto-generated
debian/rules, one will have to patch stdeb anyway, so I can't see why we
this should be added in now. It's just complexity with no gain, as far
as I can see. (That's why I removed it.)

>> I still wonder if the (now named) --disable-single-version... option
>> actually solves your problem -- you _are_ importing setuptools in the
>> same line, so I am mystified by this. 
>
> Ok, here's what happens if I DON'T use the option (shown with the old
> code - same logic):
>
> $ python setup.py  bdist_deb
> ...
> running build_scripts
> ...
> if test "2.5" = "2.5" -o "2.5" = "2.4"; then \
>          export SVEMOPT="--single-version-externally-managed" ;
> python2.5 -c "import
> setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
> install \
>            --no-compile ${SVEMOPT} \
> ...
> error: option --single-version-externally-managed not recognized
> ...
> <process stops on the error>
>
> I can't explain it, but this is what happens.  This is on Ubuntu Hardy
> using python 2.5.2.
I see. I think it's because you're subclassing distutils.command.install
rather than setuptools.command.install for your install command.

Another idea is that you could also detect whether setuptools is
imported by doing something like "if 'setuptools' in sys.modules" and
then subclassing the appropriate install command based on that. Then you
wouldn't need to pass the --disable-single-version-externally-managed
argument at all.

-Andrew