-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
As of v2023.8.19 local file dependencies default to being installed as editable #6054
Comments
In fact, it seems even if I explicitly specify |
Previously the buildpack would skip running `pipenv install` for repeat Pipenv builds if (a) the SHA256 of the `Pipfile.lock` file had not changed since the last successful build, and (b) there were no Git VCS references in the lockfile. However, this has a few issues: 1. There are other cases where it's not safe to assume that there is no need to re-run `pipenv install`, such as when installing a non-editable local dependency (see #1525), or when using editable local dependencies with the current path re-writing strategy (see #1520). 2. The current Git VCS check has false positives (see #1130, #1398). 3. Even if we try and add more checks/workarounds to resolve (1) and (2), we're still having to make assumptions about internal Pipenv implementation details, and hardcode these in the buildpack, hoping we didn't miss anything and that Pipenv's behaviour doesn't change over time (which is not the case, as seen by the recent regression pypa/pipenv#6054) As such, we now instead always re-run `pipenv install`, and defer to Pipenv to decide whether the environment needs updating. This should still be fast, since the cached `site-packages` is still being used (and if there are any scenarios in which it's not fast, then that's an upstream Pipenv bug). Integration tests were also added for various types of editable Pipenv installs, since we previously only had test coverage of editable installs for Pip. Fixes #1520. Fixes #1525. Closes #1130. Closes #1398.
Previously the buildpack would skip running `pipenv install` for repeat Pipenv builds if (a) the SHA256 of the `Pipfile.lock` file had not changed since the last successful build, and (b) there were no Git VCS references in the lockfile. However, this has a few issues: 1. There are other cases where it's not safe to assume that there is no need to re-run `pipenv install`, such as when installing a non-editable local dependency (see #1525), or when using editable local dependencies with the current path re-writing strategy (see #1520). 2. The current Git VCS check has false positives (see #1130, #1398). 3. Even if we try and add more checks/workarounds to resolve (1) and (2), we're still having to make assumptions about internal Pipenv implementation details, and hardcode these in the buildpack, hoping we didn't miss anything and that Pipenv's behaviour doesn't change over time (which is not the case, as seen by the recent regression pypa/pipenv#6054) As such, we now instead always re-run `pipenv install`, and defer to Pipenv to decide whether the environment needs updating. This should still be fast, since the cached `site-packages` is still being used (and if there are any scenarios in which it's not fast, then that's an upstream Pipenv bug). Integration tests were also added for various types of editable Pipenv installs, since we previously only had test coverage of editable installs for Pip. Fixes #1520. Fixes #1525. Closes #1130. Closes #1398.
Please help me to understand the use case(s) for wanting the local file dependency to not be "editable". |
I forget the exact reason I ran into why it ended up being to treat them all as editable, but I am willing to revisit -- I just feel I am lacking some context. |
@matteius Thank you for replying. It's slightly concerning to hear that this was in fact an intentional change after all, given that:
As for reasons why people use non-editable, I don't really have any insights into that. End users of ours reported breakages with their apps after a pipenv version upgrade. Pip supports installing any type of package (local, not local etc) in both editable and non-editable mode, as has earlier versions of pipenv. It's fine to remove a feature if it really does make implementation simpler (or if pipenv wants to be more opinionated than pip) - but this needs to be a carefully thought out, discussed and documented change. |
@edmorley I just opened a PR that modified that |
I'm not entirely sure of the best way to check. It sounds like Pipenv has little to no existing test coverage of editable installs, which is a bit concerning? (Not meant as a criticism of yourself - I know how hard it is to try and sort out a codebase with lots of tech debt - particularly an open source project done in spare time. However, when end users have a choice between a handful of package managers, things like rate of regressions really can make a difference when deciding which to choose.) The way editable installs are implemented are typically via If it were me, I'd probably check how pip or poetry write their tests for editable installs, and base them on that. |
I have a use case for non-editable installs of packages from local files. I wrote a tool to build Debian packages for applications using pipenv for dependency management (appackager, woefully underdocumented still). When writing an application, I've been using a locally-defined package that provides all the required entry points (esp. console_scripts) and a Pipfile that includes something like: [packages]
mypackage = {path = ".", editable = true} Then my Debian package builder re-writes the Pipfile.lock to set editable to false, builds a clean venv with pipenv sync, and uses that venv as the basis for the package. With the change in pipenv 2023.8.19, additional work will have to be performed on the constructed venv to make it suitable. I've described the possible workaround in issue keepertech/appackager#5 of appackager. |
I happened to spot #6222 in the changelog for Pipenv v2024.0.2, which seemed similar to this, so tested the repro here again. It looks like #6222 fixed this, since the bug no longer reproduces in v2024.0.2 (but does in v2024.0.1):
|
Issue description
Between Pipenv
2023.7.23
and2023.8.19
there was an undocumented breaking change in default installation behaviour for localfile
directory installs that don't specify an expliciteditable
property, such as:Before (in
2023.7.23
and earlier), such a dependency specifier was installed as a standard non-editable install.Now (in
2023.8.19
and later), the install is performed as an editable install - ie: as thougheditable = "true"
had been specified in thePipfile
/Pipfile.lock
.I presume this might be an unintended side-effect of #5793?
Expected result
If this behaviour change was intentional:
If this wasn't intentional:
And for bonus points either way:
editable = ....
is not explicitly specified inPipfile
) to be documented, eg at https://pipenv.pypa.io/en/latest/specifiers.html#editable-dependencies-e or similarSteps to replicate
Using https://github.com/edmorley/testcase-pipenv-file-editable:
Behaviour before (with
2023.7.23
):Behaviour now (with
2023.8.19
):Note in the second output, the
Editable project location
shows that the package was installed in editable mode, when it was not before.A package being installed in editable vs not editable mode has quite a few implications (such as whether the original location needs to be preserved for the environment to work, whether edits when developing take effect, plus the obvious path changes etc) - so a change like this is breaking, so should be mentioned in the changelog if it's intentional.
The text was updated successfully, but these errors were encountered: