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'.
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.
I still don't understand why you insist the options are to the bdist_deb
command. What is wrong with passing the options to the sdist_dsc command
where they take effect anyway?
Yes, I can see that once we got invaded with setuptools it seems you
really have no other choice.
Hang on a minute. The "st" in stdeb is for "setuptools". While in the
0.4 version this may take a less prominent role, and Distribute might be
able to step in, the ontogeny of stdeb is very much tied up with
setuptools. So I'm not comfortable promoting the idea that there ever
existed stdeb without setuptools. Maybe it can happen in the future --
but it's certainly never happened in the past.
I never said that stdeb ever existing in any other form but that of
using setuptools. I was merely making a statement as to the impact that
this has.
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.
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
Regards,
Gerry
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
