packages/lang/python/python-host.mk, branch master

python: Remove package

2020-04-02T19:26:40Z

This package will be added to the abandoned packages feed. Signed-off-by: Jeffery To

python,python3: Update host pip[3] install functions

2019-05-29T13:45:16Z

* 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

python,python3: remove `--ignore-installed` flag for host packages

2018-05-14T09:11:00Z

This was copied over from python-packages, when support for installing packages host-side (via pip) was added. Based on the discussion on this commit: https://github.com/openwrt/packages/commit/612c53fc6c3d9ba2a57f7329baf055f1d59a9246 it was mentioned that removing this may add more benefit in terms of reducing build time, because packages won't get reinstalled every time. I'm not entirely sure about any potential side-effects of this, but it's worth trying it out. Signed-off-by: Alexandru Ardelean

python,python3: export mk files outside of python package dirs

2018-01-10T21:01:51Z

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