# 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