attrs
attrs copied to clipboard
python-attrs
Drop 3.6 & switch to 100% static packaging configuration
Looks like the hatch parts will have to wait until we drop 3.6 (currently at almost 8% downloads).
https://github.com/python-attrs/attrs/pull/993/commits/b7e241d9ec0736c2a74afdc5e533698d2198a214 will probably mean some extra work for @pganssle – sorry!
To preserve my work, I've made it a draft and will try to keep it around until its time has come…
until we drop 3.6 (currently at almost 8% downloads)
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) https://github.com/psf/black/issues/3169#issuecomment-1221624251
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.
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.
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.
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.
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.
Do you want a single commit or keep individual ones? It shouldn't be hard to do with an interactive rebase.
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'm sorry for the breakage, but as @webknjaz pointed out it seems like the system is working as intended? Especially given that a warning breaking your CI seems like a conscious decision on your side?
What exactly would you have preferred to happen instead?
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.
Do you want a single commit or keep individual ones? It shouldn't be hard to do with an interactive rebase.
i just want one big patch, but i don't think that's possible to get there using rebases because there's been force-pushes so there's commits that don't exist.
i just want one big patch, but i don't think that's possible to get there using rebases
Add .diff to the PR URL for this: https://github.com/python-attrs/attrs/pull/993.diff. There's also .patch but it shows multiple commits as opposed to that huge diff.
This could be saved into a .patch file, branch force-reset to origin/main locally and applied with git am ...
Another way would be git rebase --interactive origin/main locally. It won't list the merge commits by default. You can save the rebase plan as is and see how it goes, or change pick to s or f. It'll probably give you a series of merge conflicts to solve, though, but rerere would make it easier.
Oh, and you could (being on the PR branch) just git reset --soft origin/main (would reset your branch to that point, keeping the files on disk as is) locally followed by git add . && git commit -v (this would create a commit with all the changes that remain on disk after the soft reset).
because there's been force-pushes so there's commits that don't exist.
I don't know how you drew this connection, but it hugely misinterprets the nature of Git. Git history is a blockchain — each commit has a parent, and it's sha is directly dependent on that parent and the commit contents. Yes, force-pushing replaced a bunch of commits on remote (GH) but they do exist. Also, the old commits may still in your local repo if they weren't garbage-collected. But you don't really need them for this rebase anyway.
Having merges in your feature-branch complicates the rebase, of course, but nothing's impossible. One thing that could've helped you with repeating conflict resolutions would be rerere. If you don't have it enabled, do this as soon as possible — you'll thank yourself later: https://git-scm.com/book/en/v2/Git-Tools-Rerere.
TL;DR it memorizes your manual conflict resolution results (usually the last 50, by default) and re-applies them automatically if they are faced again — this tends to happen a lot when you do rebase-driven topic branch updates.
@ofek I think I've mostly got it, just two issues / qs:
- I'm a bit surprised that coverage is working despite
coverage-enable-subprocessbeing 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
Authorfield and justAuthor-emailthat (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.
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
Authorfield and justAuthor-email
Yes https://github.com/pypa/packaging.python.org/issues/1134#issuecomment-1231564237
I believe you've created something similar for Hatch? How would I use it?
https://github.com/ofek/hatch-autorun
Cool, does https://github.com/python-attrs/attrs/pull/993/commits/68ab2e0bbbeca9efa38a92c2646429f781a349ea make sense?
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.
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.
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 .. module in docs.
This change also shouldn't be breaking unless you have a pip from 2018 or something.