Some packages just install some Python binaries, that may need their
shebang fixed.
This change adds some utilities to help with that and try to centralize the
sed rules a bit.
It also removes the logic from the `python-package-install.sh` into the
`python-package[3].mk` files. This does 2 things:
1. It minimizes the need for the shell script to know the Python
version 2/3
2. Makes the logic re-usable in packages; especially if the install rules
differ a bit
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This changes the python[3]-django dependencies in packages to be
non-selecting, and adds an MDEPENDS line so that the *-src packages get
placed inside the django menu as well.
Added MENU:= to the src-package definitions in python[3]-package.mk,
so it does not import that setting from the binary package.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
* Add --cache-dir option to set the pip cache to a directory in
$(DL_DIR), instead of pip's default (build user's ~/.cache/pip),
fixes#9066
* Add --disable-pip-version-check option, since the version check only
prints a message saying a new version is available
* Combine host_python_pip_install and host_python_pip_install_host into
Build/Compile/HostPy[3]PipInstall
* Remove --root and --prefix options, since this function is only used
to install packages to host Python's default site-packages directory
(setting these may serve to confuse pip)
* Pass all of $(HOST_PYTHON[3]_PACKAGE_BUILD_DEPENDS) to the function,
since pip can handle multiple arguments/packages
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
Some packages (PyYAML,
https://github.com/openwrt/packages/pull/8482#discussion_r270692276)
recognize "global" options to setup.py; these must appear before the
"install" command on the command line.
This adds PYTHON[3]_PKG_SETUP_GLOBAL_ARGS, which let packages set these
global options.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
Currently, all files in usr/bin (presumably all Python scripts) are run
through sed to replace the shebang; sed will overwrite the file whether
or not a match is found. This causes symlinks to be overridden and made
into copies of their targets. python[3]-base and python[3]-dev are
affected by this.
This adds the --follow-symlinks flag to sed, in addition to using
$(SED), so that symlinks are not overridden.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
If users want to define these before including python[3]-package.mk, these
vars will be overridden during the include.
So, override these vars if they haven't been defined.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This adds a variable (PYTHON_PKG_SETUP_DIR / PYTHON3_PKG_SETUP_DIR) that
allows a Python package Makefile to control the directory where setup.py
is called (as part of PyBuild/Compile/Default /
Py3Build/Compile/Default).
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This fixes Package/*/install to call PyPackage/*/install correctly.
Previously, if a package used the default PyPackage/*/install, then it
would not called. (A custom-defined PyPackage/*/install would be called
with no issue.)
Signed-off-by: Jeffery To <jeffery.to@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>
For python `src` packages we should clear out the DEPENDS
to prevent recursive deps from happening.
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>
This reverts commits 4333d1dcbf and
074d2863be, making Python packages
discoverable again by pkg_resources.
Fixes#5361.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
That way some python packages can choose
to keep their egg-info dirs, if they want to, or they're needed.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
To install Python packages host side, that
may be needed for a build.
The intent, is to try to reduce host-side Python
packages being installed via LEDE/OpenWrt build system.
Because those seem like a pain to maintain.
The idea is adapted from Yousong's `python-packages`
package.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Similar to LEDE/OpenWrt's Build/Compile/Default rule,
and other similarities like this.
This should allow Python packages to define
PyBuild/Compile rules to do specific stuff per
package.
The advantage of using these (over just overriding
Build/Compile) is the VARIANT mechanism that is
in place to support packaging both for Python & Python3.
So, PyBuild/Compile will get picked up for the Python
variant build, and Py3Build/Compile will get picked
up for the Python3 variant build.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
I admit this may be be a bit aggressive, but the lang
folder is getting cluttered/filled up with Python, PHP, Perl,
Ruby, etc. packages.
Makes sense to try to group them into per-lang folders.
I took the Pythons.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Well, they're not yet compiled, but in the next commit
they should be.
People have been complaining [citation needed] to me
via email or via Github that Python's performance is crap
because it packages sources directly and they're not compiled.
And Python has to compile the sources on each run, and
on-the-fly.
Allowing compilation caching is also a no-no, because
I'll get complaints that the flash storage fills up
whenever a Python app runs.
So, to give the user a choice, the new de-facto packaging
for Python packages will be:
* ship compiled + [ preferably ] optimized files
* package sources separately
The problem is that this doubles the number of packages
in LEDE/OpenWrt, but build-times should not suffer a big
hit, since the compilation is done once, and the
install phase should not be too intensive.
Oh, and people don't need ship source packages if
they don't want to.
To do that, a packager needs to just call
`$(eval $(call BuildPackage,python-<package>-src))`
The `python-` prefix is important.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Most python packages use the same build rules & vars.
So, adding them in python-package.mk.
Also, preparing for using VARIANTs for python/python3 packages.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Allows for more granularity with respect to python-host.mk
and python-package.mk inclusions.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
The sets host Python's prefix and exec-prefix to the same value
($(STAGING_DIR)/host for packages, as currently defined in
include/host-build.mk), which avoids the case where pyconfig.h is
not in the same location as Python's other header files (see
https://bugs.python.org/issue896330).
This also removes some cross compilation workarounds
(_python_sysroot/prefix/exec_prefix, disabling byte-compilation,
__PYVENV_LAUNCHER__) that are not necessary when compiling packages
for host.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This adds code to make it easier to build third-party python
modules such as ones from PyPi.
Signed-off-by: Daniel Dickinson <openwrt@daniel.thecshore.com>
And split python-dev and python-lib2to3 packages.
Seems for python3 this was done, so we'll sync here.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
That means basically moving the host Python from $(STAGING_DIR_HOST)
to $(STAGING_DIR_HOST)/usr and making the PYTHONPATH var
as an argument.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
python-package.mk now defines (extends) CONFIGURE_ARGS that are
adjusting PREFIX and EXEC_PREFIX in distutils.sysconfig during
compilation. These variables are sometimes used by autotools to detect
path to Python header files. Adding these variables to python-package.mk
fixes compilation of legacy autotools-configured packages that already
include python-package.mk and do not overwrite CONFIGURE_ARGS.
Signed-off-by: Jan Čermák <jan.cermak@nic.cz>
Cc: Alexandru Ardelean <ardeleanalex@gmail.com>
Packetize some Python modules to reduce size of the overall Python package.
Basically, a new package is introduced, call `python-light`,
and everything that's extra (or big) is put in other packages.
The `python` package becomes a metapackage that installs `python-light`
along with the rest of the packages.
Base work started by Jan Čermák.
Signed-off-by: Jan Čermák <jan.cermak@nic.cz>
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
That would allow for files (in filespecs) to be indented.
As it is now, the files need to be added at the begginning of the line.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems that using += adds a space in the PYTHONPATH.
Could be some other error, but at least this way
it's sure to not leave any spaces.
Thanks @Xuefer.
Signed-off-by: Xuefer Tinys <xuefer@gmail.com>
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Alexandru Ardelean
Eneas U de Queiroz
Jeffery To
Yousong Zhou
Felix Fietkau
Daniel Dickinson
Attila Lendvai
Jan Čermák
Alexandru Ardelean
Xuefer