Drop 3.6 & switch to 100% static packaging configuration #993
Conversation
|
Looks like the hatch parts will have to wait until we drop 3.6 (currently at almost 8% downloads). |
hynek
force-pushed
the
static-metadata
branch
2 times, most recently
from
13c727f
to
3acc6e4
Compare
hynek
changed the title
hynek
force-pushed
the
static-metadata
branch
4 times, most recently
from
bcaad11
to
583644b
Compare
|
oh god, can Python 3.6 do anything!?!?! |
hynek
changed the title
|
To preserve my work, I've made it a draft and will try to keep it around until its time has come… |
hynek
changed the title
What's the threshold to drop EOL versions generally? |
|
There really isn’t a threshold, but 3.6 is special because it’s the last version without dataclasses. It’s probably just in my head and the result of constant bullying by DC fans, but I have a hard time letting go. I’m thinking to add a deprecation warning for 3.6 and see how many people complain to see how much are active users and how much is just old CIs. |
|
Okay cool, was just wondering because I saw Black decided to expedite dropping 3.6 by 4 months (in ~10 days) psf/black#3169 (comment) |
|
yeah, someone may or may not have talked to one of them :) i'm happy to drop 3.6 everywhere – attrs is just special. i've deprecated 3.6 in #1017 – let's see how it goes. |
|
Needs a rebase btw |
|
yeah it's annoying…i've screwed up in the beginning I think and have to keep merging main into the branch. If there's a magic incantation for Git that will take the current diff between main and a branch and make it a single, rebased commit – i'm all ears. |
|
Merging after the new year? |
|
This DeprecationWarning broke my CI: https://github.com/ycm-core/YouCompleteMe/actions/runs/3751229771/ Is that intentional? In terms of Why, well, I guess we could just drop supper for python 3.6 too, but that seems kind of drastic. |
|
I don't think dropping support for 3.6 is not drastic as it is EOL already long ago. |
but being forced to because I can no longer make changes because my CI broke, as opposed to a "business" decision? that's the drastic part. |
|
It's not forcing anything, it's just a depreciation warning following the best practices. It's probably turned into an error according to the settings on your side (which is normally considered a best practice too). Handling such cases is your responsibility, it's just an early alert but how you integrated it is on you. If you want more CI stability, pin your test env with pip-tools-generated constraints or something. |
hynek
force-pushed
the
static-metadata
branch
2 times, most recently
from
0cfaa71
to
79ffc48
Compare
|
@ofek I think I've mostly got it, just two issues / qs:
|
hynek
force-pushed
the
static-metadata
branch
from
79ffc48
to
a1f68bc
Compare
hynek
force-pushed
the
static-metadata
branch
from
a1f68bc
to
5210764
Compare
https://github.com/ofek/hatch-autorun
|
hynek
force-pushed
the
static-metadata
branch
from
5210764
to
68ab2e0
Compare
Cool, does 68ab2e0 make sense? |
|
LGTM! |
|
Awesome! I'll wait a little bit more if I need to make a bugfix release for 22.2.0 (between the years it's unlikely someone would notice) and merge then. |
I'm pretty sure that any email parsing library would be able to retrieve that — it's one of the standardized email representations. Stdlib should do too. |
|
Sure it's an email format (still hilarious that packaging metadata is just an email envelope), but I don't think it's gonna be faster? And since I control the input, that's all that counts. |
|
Just want to know will the CI breaking change in 22.2.0 have any bug fix release? or we have to pin an older version? |
|
I'm waiting for bug reports to arrive, so far there haven't been any except for a missing This change also shouldn't be breaking unless you have a pip from 2018 or something. |
|
OK. Just FWIW encode/django-rest-framework#8828 |
|
oof |
Let's try to move into the ✨future✨.