Dropped support for 3.6 not reflected in setup.py

[fraser-langton]

It appears support has been dropped for 3.6, given use of from __future__ import annotations in pipenv/patched/notpip/_vendor/platformdirs/__init__.py:5

setup.py still showing python>=3.6

[tucked]

Please yank 2022.4.20

[matteius]

@fraser-langton Darn, we can get that dropped in the next release for sure.

@tucked I do not have permission to yank the release, but I also don't think that we should. This issue to me does not feel major enough to necessitate that. Python 3.6 support has been dropped and its EOL since 4 months ago
(23 Dec 2021), and while I acknowledge this would affect anyone that has not pinned their pip version and are still using python 3.6 -- It should be a simple matter for end users that still needs 3.6 to now pin to pip install pipenv==2022.4.8.

Although unfortunate we missed this setupy.py metadata in the review phase, I believe yanking the release would be a matter of working to support python 3.6 users further. Rather then putting undue burden on this project to yank something that resolves numerous other issue reports, I'd ask that you pin your pipenv if you are still using python 3.6. If it is determined that it definitely must be yanked, then it definitely should not be done without another new release first existing to take its place since the number of people that were waiting on the new pip 22.0.4 vendoring and the google artifactory fixes are now live with these changes.

Going to defer to @oz123 and @frostming on if I am making the right call here. If there are strong opinions that we should yank this release, then let's get the updated package that drops 3.6 metadata out there first.

[matteius]

Adding a note that it wouldn't be the first time CI and development flows have broken because of not pinning on the pipenv version, but pipenv is an actively developed project and new releases are not guaranteed to always be backwards compatible in all ways. Heroku webpack pins their version of pipenv and I think most CI's do and should. Please see also: #5026 (comment)

[fraser-langton]

@matteius yes we are pinning all instances of the install now, caused a series of build failures but yanking wouldn't solve in time as we have already done most of the fixes. In hindsight it should've been pinned already...

[matteius]

Sorry for the breakage! Working on this project has been a major learning experience; we are continuously trying to improve things and the process so will see what we can learn from this. The last time a release was yanked, it was for a major regression that was pending some work to have a fix for it. #4838
Though I see this happened also when python 2.7 support was dropped, so its easy to miss this.

Maybe there could be a CI step that could detect this type of condition, unsure of it.

[oz123]

In general, pypi doesn't allow deleting packages. It's good for auditing. The best we can do is a new release soon.

[oz123]

Just in case my response is ambiguous: no one can yank delete a published package on pypi.
I wasn't aware that yank != delete

[tucked]

@oz123 https://pypi.org/help/#yanked

[fraser-langton]

Maybe there could be a CI step that could detect this type of condition, unsure of it.
@matteius parsing the pipfile.lock and comparing the markers to what's in the setup.py could do it?

[oz123]

@oz123 https://pypi.org/help/#yanked

That's good to know. However, we lack the permissions for that currently.

[tucked]

It should be a simple matter for end users that still needs 3.6 to now pin to pip install pipenv==2022.4.8.

I install pipenv with pipx which is installed with Python 3.6.
Not yanking means pipenv breaks anytime I run pipx upgrade-all...

I believe yanking the release would be a matter of working to support python 3.6 users further.

There's a difference between not supporting and not breaking, though.

no one can yank delete a published package on pypi.

Owners can do that too (but I wouldn't advise it).

This is an open source project and I certainly appreciate the active development, so I'm definitely not complaining...
Thanks for the quick fix ☺️

[matteius]

Thanks for your feedback @tucked ... I am fine with yanking yesterday's release once we do another one -- I could do the updated release now, since that has been merged and the builds are green. I am still not sure who could yank the prior package though.