Add support for Python 3.9 #851
Conversation
|
Depends on untitaker/pytest-subtesthack#5 being released. |
|
Is there any news on python3.9 support ? I unfortunately upgraded a bit too fast... |
|
The above issue is blocking upgrading. I might look into possibly dropping the dependency is that ends up being feasible. |
|
@WhyNotHugo we're currently in the process of rebuilding all things on Arch against python3.9. I'll probably disable the tests for the time being if this is further blocked by pytest-subtesthack. |
| @@ -271,6 +271,9 @@ def get_cfg(): | |||
| } | |||
|
|
|||
|
|
|||
| hack = 0 | |||
|
The issue is that the project has vanished; there's not website for it, or anything online aside from the PyPI tarballs. |
Looks like they didn't migrate it when they moved everything else. There's a copy here but it doesn't sound (in the linked issue) like they're planning to maintain it 😞 |
|
May I ask in which state this is right now? Is the plan to remove the dependency and/or is there a way to patch around for now? EDIT: It seems that Fedora has been patching around this. https://src.fedoraproject.org/rpms/vdirsyncer/blob/rawhide/f/vdirsyncer-0.16.8-python_getiterator_deprecation.patch EDIT2: nevermind, my bad |
|
Fedora's patch seems unrelated to the above issue. The most likely course of action is to drop this dependency. What is does it run a local HTTPS server, and the test checks that vdirsyncer validates it properly. I think the simplest thing to do would be to just run the simplest HTTPS server is come docker container (e.g.: haproxy? nginx?) and use that instead. This kinda aligns with how we run CalDAV servers for tests too. The main issue with the current dependency, is that is generates certs that are too insecure by today's standards. Creating a fork of that lib and patching it seems to much burden in the long run. |
|
Travis is no longer free and we're out of credits. |
I guess that probably applies to all of pimutils? You can apply for "OSS credits" but you need to keep applying for them (so it's fine short term, but a pain longer term). Edit: Oh, actually it looks like you can ask for recurring credits. |
|
I have requested some OSS credits, let's see if this helps us. |
|
Oh, neat, thanks! |
|
I would be happy to try migrate the CI for this (and/or other projects) to an alternative CI system. Sourcehut build system (https://man.sr.ht/builds.sr.ht/) and GH Actions come to mind. |
|
@geier Have you gotten any reply from Travis? OSS credits still seem to be 0. @fourstepper I really think fixing everything on Travis first makes sense the most -- it'd be really hard to migrate CI right now since many tests are failing due to non-CI reasons (e.g.: broken dependencies, etc). However, if you want to give GitHub Actions a shot, you're more than welcome. Be warned that the CI setup for this repo is pretty non-trivial (but let me know if you've questions). |
|
nope, only got a generic "Thank you for your support request, we'll get back to you shortly" mail. The good thing about github actions would be, that we could set up our own runner. But I definitively don't have the time to port vdirsyncer. I'm trying to do this for khal at the moment (see github actions branch). Feel free to have a look everyone, help is appreciated. |
WhyNotHugo
force-pushed
the
py39
branch
2 times, most recently
from
1f8ea96
to
6dca055
Compare
The former one does not support Python 3.9.
It's embarrassing that I didn't come up with something so simple before.
WhyNotHugo
force-pushed
the
py39
branch
3 times, most recently
from
e113e58
to
1d90e93
Compare
The way it handles docker networks breaks builds.
|
I got a reply from travis on the weekend, we have 25k new credits. When they are used up, we can re-apply for more credits. |
|
Thanks for the followup. I've managed to set up CI on https://builds.sr.ht/ though, but I'll keep the credits in mind if need comes. |
|
@WhyNotHugo great! travis' loss. |
Fixes #847
Fixes #854
Also replaced Travis CI with sourcehut's offering.
ETESYNC_TESTSare currently not running, I'll address that soon separately.Only tests with Python 3.9 are running now. I'll evaluate how important it is to run the whole suite with older Pythons. I feel it might be an overkill.
However, we do have a build that runs with older dependencies. It might make sense to replace that with an Debian-based one, and actually install dependencies from Debian's repositories. Debian makes sense as a reference of "what's the oldest we're willing to support". Anyone with older dependencies around can just use an older version of vdirsyncer.