Skip to content
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

Drop 3.6 & switch to 100% static packaging configuration #993

Merged
merged 9 commits into from
Jan 11, 2023
Merged

Conversation

hynek
Copy link
Member

@hynek hynek commented Aug 6, 2022

Let's try to move into the ✨future✨.

@hynek
Copy link
Member Author

hynek commented Aug 6, 2022

Looks like the hatch parts will have to wait until we drop 3.6 (currently at almost 8% downloads).

@hynek hynek force-pushed the static-metadata branch 2 times, most recently from 13c727f to 3acc6e4 Compare August 6, 2022 06:18
@hynek hynek changed the title Switch to 100% static packaging configuration Switch to 99% static packaging configuration Aug 6, 2022
@hynek hynek force-pushed the static-metadata branch 4 times, most recently from bcaad11 to 583644b Compare August 6, 2022 08:15
@hynek
Copy link
Member Author

hynek commented Aug 6, 2022

b7e241d will probably mean some extra work for @pganssle – sorry!

@hynek
Copy link
Member Author

hynek commented Aug 6, 2022

oh god, can Python 3.6 do anything!?!?!

@hynek hynek marked this pull request as draft August 10, 2022 10:44
@hynek hynek changed the title Switch to 99% static packaging configuration Switch to 100% static packaging configuration Aug 10, 2022
@hynek
Copy link
Member Author

hynek commented Aug 10, 2022

To preserve my work, I've made it a draft and will try to keep it around until its time has come…

@hynek hynek changed the title Switch to 100% static packaging configuration Drop 3.6 & switch to 100% static packaging configuration Aug 10, 2022
hynek added a commit that referenced this pull request Aug 10, 2022
@ofek
Copy link

ofek commented Aug 21, 2022

until we drop 3.6 (currently at almost 8% downloads)

What's the threshold to drop EOL versions generally?

@hynek
Copy link
Member Author

hynek commented Aug 22, 2022

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.

@ofek
Copy link

ofek commented Aug 22, 2022

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)

@hynek
Copy link
Member Author

hynek commented Aug 22, 2022

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.

@ofek
Copy link

ofek commented Sep 21, 2022

Needs a rebase btw

@hynek
Copy link
Member Author

hynek commented Sep 21, 2022

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.

@ofek
Copy link

ofek commented Dec 12, 2022

Merging after the new year?

@hynek hynek added this to the 23.1.0 milestone Dec 18, 2022
@puremourning
Copy link

puremourning commented Dec 21, 2022

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.

@auvipy
Copy link

auvipy commented Dec 21, 2022

I don't think dropping support for 3.6 is not drastic as it is EOL already long ago.

@puremourning
Copy link

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.

@webknjaz
Copy link
Member

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
Copy link
Member Author

hynek commented Dec 30, 2022

@ofek I think I've mostly got it, just two issues / qs:

  • I'm a bit surprised that coverage is working despite coverage-enable-subprocess being for setuptools and despite complaining about "CoverageWarning: Module attrs was never imported. (module-not-imported)" – I believe you've created something similar for Hatch? How would I use it?
  • Is it on purpose that the metadata has no Author field and just Author-email that (unlike with setuptools) doesn't contain the email address but the name + email and I have to split the string to get it out? This looks very clunky.

@hynek hynek marked this pull request as ready for review December 30, 2022 14:27
@ofek
Copy link

ofek commented Dec 30, 2022

I believe you've created something similar for Hatch? How would I use it?

https://github.com/ofek/hatch-autorun

Is it on purpose that the metadata has no Author field and just Author-email

Yes pypa/packaging.python.org#1134 (comment)

@hynek
Copy link
Member Author

hynek commented Dec 30, 2022

I believe you've created something similar for Hatch? How would I use it?

https://github.com/ofek/hatch-autorun

Cool, does 68ab2e0 make sense?

@ofek
Copy link

ofek commented Dec 30, 2022

LGTM!

@hynek
Copy link
Member Author

hynek commented Dec 30, 2022

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.

@webknjaz
Copy link
Member

and I have to split the string to get it out?

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.

@hynek
Copy link
Member Author

hynek commented Dec 30, 2022

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.

@auvipy
Copy link

auvipy commented Jan 3, 2023

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?

@hynek
Copy link
Member Author

hynek commented Jan 3, 2023

I'm waiting for bug reports to arrive, so far there haven't been any except for a missing .. module in docs.

This change also shouldn't be breaking unless you have a pip from 2018 or something.

@auvipy
Copy link

auvipy commented Jan 3, 2023

OK. Just FWIW encode/django-rest-framework#8828

@hynek hynek merged commit d4934b1 into main Jan 11, 2023
@hynek hynek deleted the static-metadata branch January 11, 2023 15:50
@hynek
Copy link
Member Author

hynek commented Jan 11, 2023

oof

hynek added a commit that referenced this pull request Feb 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants