weberc2
commented
5 years ago Possible solution: Create a low-level target that all Python target types depend on; update the build scripts to exec this Python (in a venv w/ wheel installed) and its corresponding pip instead of system python and system pip.
- The target that all Python target types will depend on will have to represent a new Python installation with just the wheel package installed.
- This can be a "install the wheel package" target that depends on the "base Python installation" target (optionally with a virtualenv in there somewhere) or it can be one target that does everything (this comment isn't trying to be prescriptive)
- Ideally, the user will be prevented from modifying this Python environment (e.g., pip installing other packages). This might be achievable via filesystem permissions. This is a special case of #27, but this is a particularly important special case because the Python base target seems more likely to accidentally mutate (because the Python toolchain--e.g., pip--is too hard to reason about and may well mutate things unexpectedly).
- The base Python installation should be confined to the cache; it shouldn't have components scattered across the system except for its own system dependencies (breaking low-level system dependencies--e.g., libc--is not a goal of this project).
- If there is a virtualenv that all Python commands run in, I believe all that is necessary to "activate" the virtualenv is to run the Python interpreter in that virtualenv; from there, the Python interpreter will know its own path and find virtualenv dependencies as relative paths from itself.
- The generic "install from pypi" target type depends on the wheel package being installed; since wheel is itself a package from pypi, it won't be possible to use the "install from pypi" target type to install the wheel package; it is probably necessary to implement a "download wheel package from pypi" that does not depend on the wheel package. This might be a good point to introduce some notion of a scriptable target type (perhaps a bash target type?) (#28).
Right now the Python plugin depends on system python; the plugin should "build" its own Python(s) at the right version and reference them from the cache.