[Rpm-maint] [rpm-software-management/rpm] Provide a way to opt out from automagic Python bytecompilation (#434)

Jeff Johnson notifications at github.com
Tue Apr 24 19:49:50 UTC 2018


Au contraire: one can write magic pattern rules to match syntactical variants of *.py and emit the interpreter to be used to interpret a file exactly like MIME was designed for.

But I digress: writing correct/useful magic pattern rules based on syntax is hugely fragile and a black art.

Meanwhile, there is no reason I know of that an ordered list of python interpreters in PATH (or in /usr/bin if you must) cannot be tested for existence and use the first found interpreter to byte compile.

That certainly works for all the possible variant versions of, say, python2-X.Y where mock/yum/dnf are processing BuildRequires: to set up an isolated chroot or vm build system.

(aside)
You can can also "best effort" automate python2 -> python3 conversion/coercion within the byte compilation loop if you are clever and brave.

And no existing package needs to be changed if you are careful: just ignore the older technique of passing the python interpreter to use for byte compilation. Alternatively, fail/warn the build if when the automagically detected interpreter version disagrees with what is passed in and use whichever of the 2 values you prefer.

If you do not like to abuse the execute bit as an enabler/disabler then simply "Don't do that."

But adding packager driven macro enabler/disabler infrastructure instead of changing a script seems a grossly ignorant hack (to me).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/434#issuecomment-384057549
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20180424/d2d9313d/attachment.html>


More information about the Rpm-maint mailing list