# Python Rewrite notes **Resources** [Overview of dep management](https://modelpredict.com/python-dependency-management-tools#usual-setups) **Important general questions** * What are the popular python setups? * Which tools/setups should we support? ## Current state 3 high level types of apps: - Pipfile with deps - Req.txt with deps - Conda app **Important points for RFC** **pipenv generates a req.txt file from pipfile.lock. Why were things implemented the way they are? Is there a good reason not to utilize pipenv commands?** **Context from Slack:** The above implementation was chosen for the following reasons: > - you can have both a requirements.txt and pipenv file in a project (or at least we supported this in the v2b buildpack) > - pipenv creates a virtualenv and as a result can install its own version of python (not the ones we build and support in the buildpack) **Update:** It is possible to create separate layers for pip, pipenv and python and install an app's dependencies successfully using the `pipenv install --deploy --system` command. The `--deploy` flag ensures that Pipfile.lock is up-to-date, while the `--system` flag ensures that the Pipfile dependencies are installed into the parent system. When running `pip install`, you need to specify the `--user` flag or set the `PIP_USER` environment variable. The packages installed by `pip` will end up in the path specified by `PYTHONUSERBASE`. Once those packages are installed, they should be included on the `PYTHONPATH`. The `PYTHONPATH` works like `PATH` for looking up Python packages. The expectation is that the directory is the `site-packages` directory under the installation location. For example, if I set `PYTHONUSERBASE` to `/tmp` and run `pip install --user SomePackage`, then I can expect to see that package at `/tmp/lib/python<version>/site-packages/SomePackage`. However, I will need to append `/tmp/lib/python<version>/site-packages` onto the `PYTHONPATH` so that the Python runtime can find `SomePackage` when it is imported in my program. **What are the default start commands for supported workflows? How should "start command" buildpacks function for this language family?** Actions: - ~~Reach out to Dan Thorton & David Freilich [TH && FE]~~ - Start RFC skeleton Unresolved Questions: **How might we optimize layer caching for conda environments?** Conda creates wholesale copies of dependencies for each environment(?) This may eliminate the layer caching/reuse benefits afforded by the buildpack by mandating a full layer rebuild whenever environment packages change. [Conversation about this issue](https://github.com/GoogleCloudPlatform/buildpacks/issues/45) [PEP 518](https://www.python.org/dev/peps/pep-0518/#specification) [What the heck is pyproject.toml](https://snarky.ca/what-the-heck-is-pyproject-toml/) ~~[Python projects using `pyproject.toml`](https://github.com/carlosperate/awesome-pyproject)~~ ### Proposal Continue to have pip, pipenv and python-runtime (renamed to cpython) buildpacks which simply install the dependencies they are named for Create pip-install, pipenv-install buildpacks which perform the installation of dependencies. Split conda buildpack into constituent-step buildpacks