[Bug 526126] Review Request: python3 - Python 3.x (backwards incompatible version)

bugzilla at redhat.com bugzilla at redhat.com
Fri Oct 23 00:47:27 UTC 2009


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=526126





--- Comment #30 from Andrew McNabb <amcnabb at mcnabbs.org>  2009-10-22 20:47:22 EDT ---
(In reply to comment #29)
> 
> I want to build up a full python 3 stack, and a problem is that every
> python3-foo module package will need to have a similar construction, and this
> could get messy fast.  So this probably needs fixing in rpmbuild, fixing things
> so that the /usr/lib/rpm/brp-python-bytecompile script can somehow be told
> which python implementation to use (it can accept an argument, but that's not
> how it's getting invoked).  Perhaps an environment variable can be used? 
> "RPMBUILD_PYTHON_INTERPRETER", or somesuch?

I think that sounds like a good idea.  The only problem is that within the
python3.spec, we couldn't just set `RPMBUILD_PYTHON_INTERPRETER=./python`
because this interpreter also needs to be called with `LD_LIBRARY_PATH=.`.  And
it would be a shame to change brp-python-bytecompile in a way that didn't help
at all for python3.spec.  Hmm.


> Unfortunately, the find/sed/chmod is corrupting
>   /usr/lib/python3.1/test/test_httpservers.py
> due to a line beginning with a shebang embedded deep in the file, which is
> causing
>   grep -m 1 -q '^#!' ~/rpmbuild/BUILD/Python-3.1.1/Lib/test/test_httpservers.py
> to match, and then the "sed" command strips out the first line of the file,
> which isn't a shebang line (and thus the file becomes syntactically invalid :-(
> )

Hmm.  Is it really necessary to remove the shebang lines from .py files that
aren't executable?  I think it's a complicated (and error-prone) step that
doesn't have any tangible value.


> grep's "-m" option doesn't seem to be quite what's needed here for restricting
> the shebang search to the first line in the file; any suggestions on fixing
> this?  (I tried using "head -n1 | grep", but am unsure of the correct way to
> embed that in the "find -exec" clause.

If this step is really necessary, the only way to embed "head -n1 |grep" is to
offload it into a standalone shell script.  Alternatively, you could use sed:

sed -e '/^#!/Q 0' -e 'Q 1' {}

It will return 0 if the shebang is found and 1 otherwise.  Hey, that's actually
pretty cool, in a sick way. :)

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.




More information about the Fedora-package-review mailing list