Delete deprecated host-environment-markers key
#7698
Merged
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
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.
mctofu
approved these changes
Aug 2, 2023
abdulapopoola
approved these changes
Aug 2, 2023
jeffwidman
added
L: elixir:hex
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.
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.
Our
pipenvfixtures 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-markerskey 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:
host-environment-markersneed to be in Pipfile.lock? pypa/pipenv#753In 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:pipenvdue to conflicts with Python3.6, etc: Bump pipenv to 2022.11.5 #6104Since we will soon be dropping Python 3.6, 3.7, and then planning to update
pipenvversion, 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:pipenvlockfiles: Regeneratepipenvlockfiles used as test fixtures #7697pipenvpipenv lock.So in this PR I manually deleted the key... but note that I was forced to do so manually not programmatically, so these fixtures may still be outdated in other ways.