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
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
