-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Perform editable package .pth and .egg-link path rewriting at runtime #1252
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
260606d
to
5dba58c
Compare
Nice one, @edmorley. Two questions:
|
@dzuelke Yes to (1). For (2), the issue is that the |
The editable package tests now output the contents of all of the `.pth` and `.egg-link` files in `site-packages` to aid debugging, as well as help demonstrate the changes that will be taking place in #1252. GUS-W-10047026. [skip changelog]
5dba58c
to
b373416
Compare
Currently the build system performs builds in a different directory (`/tmp/build_<hash>`) to which the app will be run at runtime (`/app`). This means that any hardcoded paths in the slug must be rewritten by the buildpack, so the app still works after being moved. One such case of hardcoded paths, are the `.pth` and `.egg-link` files that are created in the `site-packages` directory by Pip/setuptools for editable package installs (aka develop mode). The most common way someone might use editable mode is via `-e <package specifier>` entries in their `requirements.txt` file. Until now, the Python buildpack rewrote paths inside these files during the compile itself, which meant the build-time paths were no longer present when subsequent buildpacks ran. This happened to work due to an interaction of legacy setuptools behaviour and a buildpack bug, but stops working in setuptools 47.2.0 or later - as described in #1006. Longer term we would like to stop building in one location and running the app from another, so that the path rewriting isn't required at all. However that change breaks some other buildpacks so requires a long-term transition plan. In the meantime, this change moves path rewriting to a `.profile.d/` script, so that it occurs at runtime, and so after all other buildpacks have run. Additional test coverage of editable packages was added previously in #1251 and #1253, and has confirmed that this new `profile.d/` script approach will prevent the issues in #1006 when setuptools is updated in a future PR. There is one subtle implication of moving this path rewriting, in that subsequent cached builds will no longer see the existing package as being already installed, so won't uninstall if before reinstalling it (as seen in the test log output change). However this is not believed to have any significant impact. Fixes #1006. (And so unblocks updating to the newer setuptools required for #1248.)
b373416
to
0136a15
Compare
Updates: - setuptools from 47.1.1 to: - 50.3.2 for Python 3.5 - 57.5.0 for Python 3.6+ - wheel from 0.36.2 to 0.37.0. Of note, the newer setuptools is fully compatible with Python 3.10, thereby fixing #1248. Updating to newer setuptools was blocked on #1006, but that's now been fixed by #1252. The setuptools version hasn't been updated all the way to the latest (58.2.0), since v58 dropped support for 2to3, which caused breakage in a few packages, so I would rather hold off as long as possible (and there are no fixes that we need since then). Release notes: https://setuptools.pypa.io/en/latest/history.html#v57-5-0 https://wheel.readthedocs.io/en/stable/news.html Full changelogs: pypa/setuptools@v47.1.1...v57.5.0 pypa/wheel@0.36.2...0.37.0 Fixes #1248. GUS-W-10052807.
Updates: - setuptools from 47.1.1 to: - 50.3.2 for Python 3.5 - 57.5.0 for Python 3.6+ - wheel from 0.36.2 to 0.37.0. Of note, the newer setuptools is fully compatible with Python 3.10, thereby fixing #1248. Updating to newer setuptools was blocked on #1006, but that's now been fixed by #1252. The setuptools version hasn't been updated all the way to the latest (58.2.0), since v58 dropped support for 2to3, which caused breakage in a few packages, so I would rather hold off as long as possible (and there are no fixes that we need since then). Release notes: https://setuptools.pypa.io/en/latest/history.html#v57-5-0 https://wheel.readthedocs.io/en/stable/news.html Full changelogs: pypa/setuptools@v47.1.1...v57.5.0 pypa/wheel@0.36.2...0.37.0 Fixes #1248. GUS-W-10052807.
Currently the build system performs builds in a different directory (
/tmp/build_<hash>
) to which the app will be run at runtime (/app
). This means that any hardcoded paths in the slug must be rewritten by the buildpack, so the app still works after being moved.One such case of hardcoded paths, are the
.pth
and.egg-link
files that are created in thesite-packages
directory by Pip/setuptools for editable package installs (aka develop mode). The most common way someone might use editable mode is via-e <package specifier>
entries in theirrequirements.txt
file.Until now, the Python buildpack rewrote paths inside these files during the compile itself, which meant the build-time paths were no longer present when subsequent buildpacks ran. This happened to work due to an interaction of legacy setuptools behaviour and a buildpack bug, but stops working in setuptools 47.2.0 or later - as described in #1006.
Longer term we would like to stop building in one location and running the app from another, so that the path rewriting isn't required at all. However that change breaks some other buildpacks so requires a long-term transition plan (internal notes).
In the meantime, this change moves path rewriting to a
.profile.d/
script, so that it occurs at runtime, and so after all other buildpacks have run.Additional test coverage of editable packages was added previously in #1251, and has confirmed that this new
profile.d/
script approach will prevent the issues in #1006 when setuptools is updated in a future PR.There is one subtle implication of moving this path rewriting, in that subsequent cached builds will no longer see the existing package as being already installed, so won't uninstall if before reinstalling it (as seen in the test log output change). However this is not believed to have any significant impact.
Fixes #1006. (And so unblocks updating to the newer setuptools required for #1248.)
GUS-W-7828034.