This extends the Python[3] shebang fixup to all packages.
Only Python scripts in `/usr/bin` will be handled at the moment. Later it
may make sense to also cover executables in `/bin`, though typically Python
executables shouldn't be placed there.
Previously the shebang handling was only done for python[3]-pip &
python[3]-setuptools.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Piping to xargs does not handle spaces in paths too well, because it splits
up the paths.
For deleting empty dirs, we also need to do several retries, otherwise
`find` will try to go through the directories after they're deleted.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
It's a common operation for both Python & Python3, so move it to the
script `python-package-install.sh` script.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Following a discussion on bugs.python.org:
* https://bugs.python.org/issue29708
* https://bugs.python.org/msg313384
It seems that setting a fixed value to PYTHONHASHSEED guarantees that
the bytecodes are generated consistently/in a reproducible manner.
Hopefully, this is the last bit to make Python3 build reproducible.
Tested this locally on a few files [that were not reproducible without
this change].
The PYTHONHASHSEED is only assigned to the host Python/Python3 during
compilation of byte-codes [from python source].
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
The only difference just a parameter for Python3
[ -b to compile bytecodes in legacy mode ].
No need to keep 2 almost identical files now
that they're exported.
I'm a bit scared of that param, since it may get
removed at some point.
But let's see until then.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Since `lang/python` is it's own folder of Python packages
(for both Python 2 & 3), and these build rules are needed
in a lot of packages [especially Python packages],
putting them here makes sense architecturally,
to be shared.
This also helps get rid of the `include_mk` construct
which relies on OpenWrt core to provide, and seems
like a broken design idea that has persisted for a while.
Reason is: it requires that Python 2/3 be built to provide
these mk files for other Python packages,
which seems like a bad idea.
Long-term, there could be an issue where some other feeds
would require these mk files [e.g. telephony] for
some Python packages.
We'll see how we handle this a bit later.
For now we limit this to this feed.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
2018-01-10 23:01:51 +02:00
Renamed from lang/python/python/files/python-package-install.sh (Browse further)
