Skip to content

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

Merged
merged 1 commit into from
Oct 19, 2021

Conversation

edmorley
Copy link
Member

@edmorley edmorley commented Oct 19, 2021

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 (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.

@edmorley edmorley added the bug label Oct 19, 2021
@edmorley edmorley requested a review from a team as a code owner October 19, 2021 12:25
@edmorley edmorley self-assigned this Oct 19, 2021
@edmorley edmorley force-pushed the fix-editable-path-rewriting branch from 260606d to 5dba58c Compare October 19, 2021 12:55
@dzuelke
Copy link
Contributor

dzuelke commented Oct 19, 2021

Nice one, @edmorley.

Two questions:

  1. am I understanding the tests from Tests: Add additional coverage of editable package installation #1251 correctly: they're verifying that another buildpack ("inline", in that case) can successfully use the packages at build time?
  2. Python doesn't resolve symlinks inside egg file loads, and that's why you can't rewrite the paths to /app/.heroku/python/ ahead of time? These symlinks will still be there when a subsequent buildpack runs, after all.

@edmorley
Copy link
Member Author

edmorley commented Oct 19, 2021

@dzuelke Yes to (1).

For (2), the issue is that the .pth and .egg-link files don't just contain paths under .heroku/python/ but also to the app source too (in the case of local directory installs rather than VCS installs), and the app source isn't symlinked under /app. I'll cat the contents of the .pth and .egg-link files in the tests to make their contents easier to reason about (I'll add this in another PR, so the before/after can be seen in this PR once rebased).

@edmorley
Copy link
Member Author

@dzuelke Additional test log output (that makes it easier to see what this PR does, and why it's needed) added in #1253 - please review and I'll rebase this PR on top.

edmorley added a commit that referenced this pull request Oct 19, 2021
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]
@edmorley edmorley force-pushed the fix-editable-path-rewriting branch from 5dba58c to b373416 Compare October 19, 2021 14:47
@edmorley edmorley requested a review from dzuelke October 19, 2021 14:49
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.)
@edmorley edmorley force-pushed the fix-editable-path-rewriting branch from b373416 to 0136a15 Compare October 19, 2021 14:51
@edmorley edmorley merged commit 24b892e into main Oct 19, 2021
@edmorley edmorley deleted the fix-editable-path-rewriting branch October 19, 2021 16:28
edmorley added a commit that referenced this pull request Oct 19, 2021
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.
edmorley added a commit that referenced this pull request Oct 19, 2021
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Editable installs don't work with setuptools 47.2.0+ and multi-buildpack
3 participants