Bump pipenv to 2022.11.5 #6104
Closed
Bump pipenv to 2022.11.5 #6104
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
To fix undeterminism when generating `python_version` and `python_full_version` markers.
pavera
reviewed
Nov 14, 2022
1 task
1 task
|
There were only a few validation constraints that mattered when we switched from Pipfile to plette -- from the test failures I can see one of them identified: the sources have to have a |
|
so what's the plan here? drop supporting older python? create fork and make pipenv that's compatible with your python versions? use different versions as noted here? had to fix yet another bug caused by the ecosystem: |
We're planning to drop support for python 3.6 which will unblock this: Timing is still TBD, see that issue for details. |
This was referenced Mar 14, 2023
Merged
jeffwidman
added a commit
that referenced
this pull request
Mar 22, 2023
Unfortunately, bumping to the latest version of `pipenv` is currently blocked on us dropping support for Python 3.6: * #6104 (comment) So for now let's clarify the comment with a TODO... This whole bit of code may also get redone if we switch the interface we use: * #6836 But for now let's capture some notes until we can devote more time to this.
jeffwidman
added a commit
that referenced
this pull request
Mar 22, 2023
Unfortunately, bumping to the latest version of `pipenv` is currently blocked on us dropping support for Python 3.6: * #6104 (comment) So for now let's clarify the comment with a TODO... This whole bit of code may also get redone if we switch the interface we use: * #6836 But for now let's capture some notes until we can devote more time to this.
jeffwidman
added a commit
that referenced
this pull request
Mar 22, 2023
Unfortunately, bumping to the latest version of `pipenv` is currently blocked on us dropping support for Python 3.6: * #6104 (comment) So for now let's clarify the comment with a TODO... This whole bit of code may also get redone if we switch the interface we use: * #6836 But for now let's capture some notes until we can devote more time to this.
jeffwidman
added a commit
that referenced
this pull request
Mar 22, 2023
Unfortunately, bumping to the latest version of `pipenv` is currently blocked on us dropping support for Python 3.6: * #6104 (comment) So for now let's clarify the comment with a TODO... This whole bit of code may also get redone if we switch the interface we use: * #6836 But for now let's capture some notes until we can devote more time to this.
jeffwidman
added a commit
that referenced
this pull request
Aug 2, 2023
Our `pipenv` fixtures are a bit outdated... when I tried to delete Python 3.6, they started failing because we've got some code that reads the python version and tries to use that to guess at what version of python to run. However, when I tried regenerating one of these lockfiles under a newer Python, I was surprised that the entire `host-environment-markers` key disappeared. After a little digging, I found that this key was removed in 2018, which also explains why only the older fixtures have it and not the more recent fixtures. More historical context: * pypa/pipenv#753 * pypa/pipenv@ecf7842#r28870534 * pypa/pipenv@ecf7842#diff-ef852c4ac364f946819f765a6bc26f04f1b0968f31fc512949a60fa2ab0685e8L1201 In order to update our lockfiles, I first started by running `PYENV_VERSION=3.11.4 pyenv exec pipenv lock`... However, I ran into some problems because: 1. Some of the lockfiles are simply unresolvable by design in order to stress test our code. So they have to be manually munged around. 2. We are currently pinned to an olde version of `pipenv` due to conflicts with Python `3.6`, etc: #6104 Since we will soon be dropping Python 3.6, 3.7, and then planning to update `pipenv` version, I decided it would be more efficient from an engineering perspective to hack my way through the jungle with a machete for a little bit by: 1. Manually delete the key from the lockfiles (that's what this PR does) 2. File a ticket to track regenerating the `pipenv` lockfiles: #7697 3. Finish the work of deprecating EOL'd python versions and updating `pipenv` 4. Then finally regenerate the fixtures using `pipenv lock`. So in this PR I manually deleted the key... but note that I did so manually not programmatically, so these fixtures may still be outdated in other ways.
jeffwidman
added a commit
that referenced
this pull request
Aug 2, 2023
Our `pipenv` fixtures are a bit outdated... when I tried to delete Python 3.6, they started failing because we've got some code that reads the python version and tries to use that to guess at what version of python to run. However, when I tried regenerating one of these lockfiles under a newer Python, I was surprised that the entire `host-environment-markers` key disappeared. After a little digging, I found that this key was removed in 2018, which also explains why only the older fixtures have it and not the more recent fixtures. More historical context: * pypa/pipenv#753 * pypa/pipenv@ecf7842#r28870534 * pypa/pipenv@ecf7842#diff-ef852c4ac364f946819f765a6bc26f04f1b0968f31fc512949a60fa2ab0685e8L1201 In order to update our lockfiles, I first started by running `PYENV_VERSION=3.11.4 pyenv exec pipenv lock`... However, I ran into some problems because: 1. Some of the lockfiles are simply unresolvable by design in order to stress test our code. So they have to be manually munged around. 2. We are currently pinned to an olde version of `pipenv` due to conflicts with Python `3.6`, etc: #6104 Since we will soon be dropping Python 3.6, 3.7, and then planning to update `pipenv` version, I decided it would be more efficient from an engineering perspective to hack my way through the jungle with a machete for a little bit by: 1. Manually delete the key from the lockfiles (that's what this PR does) 2. File a ticket to track regenerating the `pipenv` lockfiles: #7697 3. Finish the work of deprecating EOL'd python versions and updating `pipenv` 4. Then finally regenerate the fixtures using `pipenv lock`. So in this PR I manually deleted the key... but note that I did so manually not programmatically, so these fixtures may still be outdated in other ways.
jeffwidman
reviewed
Aug 3, 2023
| ) | ||
| File.write("dev-req.txt", dev_req_content) | ||
| end | ||
|
|
||
| def run_command(command, env: {}) | ||
| start = Time.now | ||
| command = SharedHelpers.escape_command(command) | ||
| stdout, process = Open3.capture2e(env, command) | ||
| stdout, _, process = Open3.capture3(env, command) |
There was a problem hiding this comment.
This was extracted out separately into:
jeffwidman
reviewed
Aug 3, 2023
| @@ -233,20 +233,20 @@ def post_process_lockfile(updated_lockfile_content) | |||
|
|
|||
| def generate_updated_requirements_files | |||
| req_content = run_pipenv_command( | |||
| "pyenv exec pipenv lock -r" | |||
| "pyenv exec pipenv requirements" | |||
There was a problem hiding this comment.
I think we'll instead want to long-term go with:
|
I'm going to close this PR in favor of: I suspect we'll hit the same test failures, but we can work through them over there... and may end up migrating to the new |
jeffwidman
added a commit
that referenced
this pull request
Aug 5, 2023
The main user of `pipfile` is `pipenv`, and _not_ any of the other python package managers. However, `pipfile` library has been pretty much unmaintained, so `pipenv` switched to using `plette` for parsing/validation of `Pipfile`'s: * pypa/pipenv#5310 * pypa/pipenv#5339 So let's switch our usage as well. Today we only use `pipfile` for generating hashes, so this is effectively a silent no-op. However, down the road we could leverage `plette` for `Pipfile` parsing/validation... for example see how it's flagging things here: #6104 (comment)
jeffwidman
added a commit
that referenced
this pull request
Aug 10, 2023
The main user of `pipfile` is `pipenv`, and _not_ any of the other python package managers. However, `pipfile` library has been pretty much unmaintained, so `pipenv` switched to using `plette` for parsing/validation of `Pipfile`'s: * pypa/pipenv#5310 * pypa/pipenv#5339 So let's switch our usage as well. Today we only use `pipfile` for generating hashes, so this is effectively a silent no-op. However, down the road we could leverage `plette` for `Pipfile` parsing/validation... for example see how it's flagging things here: #6104 (comment)
jeffwidman
added a commit
that referenced
this pull request
Aug 23, 2023
The main user of `pipfile` is `pipenv`, and _not_ any of the other python package managers. However, `pipfile` library has been pretty much unmaintained, so `pipenv` switched to using `plette` for parsing/validation of `Pipfile`'s: * pypa/pipenv#5310 * pypa/pipenv#5339 So let's switch our usage as well. Today we only use `pipfile` for generating hashes, so this is effectively a silent no-op. However, down the road we could leverage `plette` for `Pipfile` parsing/validation... for example see how it's flagging things here: #6104 (comment)
brettfo
pushed a commit
to brettfo/dependabot-core
that referenced
this pull request
Oct 11, 2023
Our `pipenv` fixtures are a bit outdated... when I tried to delete Python 3.6, they started failing because we've got some code that reads the python version and tries to use that to guess at what version of python to run. However, when I tried regenerating one of these lockfiles under a newer Python, I was surprised that the entire `host-environment-markers` key disappeared. After a little digging, I found that this key was removed in 2018, which also explains why only the older fixtures have it and not the more recent fixtures. More historical context: * pypa/pipenv#753 * pypa/pipenv@ecf7842#r28870534 * pypa/pipenv@ecf7842#diff-ef852c4ac364f946819f765a6bc26f04f1b0968f31fc512949a60fa2ab0685e8L1201 In order to update our lockfiles, I first started by running `PYENV_VERSION=3.11.4 pyenv exec pipenv lock`... However, I ran into some problems because: 1. Some of the lockfiles are simply unresolvable by design in order to stress test our code. So they have to be manually munged around. 2. We are currently pinned to an olde version of `pipenv` due to conflicts with Python `3.6`, etc: dependabot#6104 Since we will soon be dropping Python 3.6, 3.7, and then planning to update `pipenv` version, I decided it would be more efficient from an engineering perspective to hack my way through the jungle with a machete for a little bit by: 1. Manually delete the key from the lockfiles (that's what this PR does) 2. File a ticket to track regenerating the `pipenv` lockfiles: dependabot#7697 3. Finish the work of deprecating EOL'd python versions and updating `pipenv` 4. Then finally regenerate the fixtures using `pipenv lock`. So in this PR I manually deleted the key... but note that I did so manually not programmatically, so these fixtures may still be outdated in other ways.
jeffwidman
added a commit
to jeffwidman/dependabot-core
that referenced
this pull request
Dec 15, 2023
The main user of `pipfile` is `pipenv`, and _not_ any of the other python package managers. However, `pipfile` library has been pretty much unmaintained, so `pipenv` switched to using `plette` for parsing/validation of `Pipfile`'s: * pypa/pipenv#5310 * pypa/pipenv#5339 So let's switch our usage as well. Today we only use `pipfile` for generating hashes, so this is effectively a silent no-op. However, down the road we could leverage `plette` for `Pipfile` parsing/validation... for example see how it's flagging things here: dependabot#6104 (comment)
jeffwidman
added a commit
to jeffwidman/dependabot-core
that referenced
this pull request
Dec 16, 2023
The main user of `pipfile` is `pipenv`, and _not_ any of the other python package managers. However, `pipfile` library has been pretty much unmaintained, so `pipenv` switched to using `plette` for parsing/validation of `Pipfile`'s: * pypa/pipenv#5310 * pypa/pipenv#5339 So let's switch our usage as well. Today we only use `pipfile` for generating hashes, so this is effectively a silent no-op. However, down the road we could leverage `plette` for `Pipfile` parsing/validation... for example see how it's flagging things here: dependabot#6104 (comment)
jeffwidman
added a commit
to jeffwidman/dependabot-core
that referenced
this pull request
Dec 16, 2023
The main user of `pipfile` is `pipenv`, and _not_ any of the other python package managers. However, `pipfile` library has been pretty much unmaintained, so `pipenv` switched to using `plette` for parsing/validation of `Pipfile`'s: * pypa/pipenv#5310 * pypa/pipenv#5339 So let's switch our usage as well. Today we only use `pipfile` for generating hashes, so this is effectively a silent no-op. However, down the road we could leverage `plette` for `Pipfile` parsing/validation... for example see how it's flagging things here: dependabot#6104 (comment)
jeffwidman
added a commit
to jeffwidman/dependabot-core
that referenced
this pull request
Dec 16, 2023
The main user of `pipfile` is `pipenv`, and _not_ any of the other python package managers. However, `pipfile` library has been pretty much unmaintained, so `pipenv` switched to using `plette` for parsing/validation of `Pipfile`'s: * pypa/pipenv#5310 * pypa/pipenv#5339 So let's switch our usage as well. Today we only use `pipfile` for generating hashes, so this is effectively a silent no-op. However, down the road we could leverage `plette` for `Pipfile` parsing/validation... for example see how it's flagging things here: dependabot#6104 (comment)
jeffwidman
added a commit
to jeffwidman/dependabot-core
that referenced
this pull request
Mar 21, 2024
The main user of `pipfile` is `pipenv`, and _not_ any of the other python package managers. However, `pipfile` library has been pretty much unmaintained, so `pipenv` switched to using `plette` for parsing/validation of `Pipfile`'s: * pypa/pipenv#5310 * pypa/pipenv#5339 So let's switch our usage as well. Today we only use `pipfile` for generating hashes, so this is effectively a silent no-op. However, down the road we could leverage `plette` for `Pipfile` parsing/validation... for example see how it's flagging things here: dependabot#6104 (comment)
abdulapopoola
added a commit
that referenced
this pull request
Mar 22, 2024
The main user of `pipfile` is `pipenv`, and _not_ any of the other python package managers. However, `pipfile` library has been pretty much unmaintained, so `pipenv` switched to using `plette` for parsing/validation of `Pipfile`'s: * pypa/pipenv#5310 * pypa/pipenv#5339 So let's switch our usage as well. Today we only use `pipfile` for generating hashes, so this is effectively a silent no-op. However, down the road we could leverage `plette` for `Pipfile` parsing/validation... for example see how it's flagging things here: #6104 (comment) Co-authored-by: AbdulFattaah Popoola <abdulapopoola@github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I think this PR would fix #6091 if it was acceptable, because it includes pypa/pipenv#5373 which I believe fixes exactly the issue reported at #6091.
However, it seems to introduce several other noise in manifest file diffs, although at least it's deterministic.
In addition to this, I think it no longer works with Python 3.6 according to pypa/pipenv#5406, so I guess we can't bump it just yet.
Fixes #6091.