Yes, the final dot release came out very recently. Python EOL dates are aggregated on https://devguide.python.org/devcycle/, and also in individual release schedule PEPs.
Personally, I think outside `typing` and significant `asyncio` changes, Python 3.5 didn't bring as many improvements as Python 3.4 (highly visible ones scattered all over PSL), nor did it come with sweeping new features with wide-ranging impact like Python 3.6 (f-strings, fspath protocol, etc.), so it should be fairly easy to support non-type-annotated code on Python 3.4 alongside 3.5. The only important thing I can think of is unpacking generalizations. Personally I would take a support-it-unless-it-actually-hinders-development approach.
Have you tried the local CLI? It should show you everything that was run inside the container.
And for the remote version, every job has a "rerun job with SSH" option on the top right dropdown, which allows you to SSH into the remote container to poke around. Pretty helpful.
Um, you need to contact their sales department to get a limited free option for macOS builds: https://circleci.com/open-source/. Maybe not worth the trouble. (Your call apparently.)
Sure, will do. (In my defense, I consider this more of a regression than a feature.)
Done: https://requests.requarks.io/wiki/p/option-to-avoid-external-requests-to-cdnjs-and-google-fonts-in-v2
Another comment on CircleCI: in case you don't know this, for jobs using the docker executor (basically anything that doesn't need direct access to the `docker` command — `packagecore` is an outlier), they have a CLI that allows testing locally. So no more shooting in the dark and waiting in the queue over and over again when updating the CI config, for the most part.
(Also, thanks to first class Docker support, we can use any image — there's no waiting for their support for any language toolchain/runtime. Of course, that was possible with Docker-enabled Travis instances too — I used to get around trusty limitations that way on Travis — but to have clear build/test steps one needs to manually wrap each step in a `docker run` which is very ugly.)
> First build passed. And it's much faster than Travis!
Yeah, the docker executor startup is instant, and 4x concurrency for open source projects beats Travis (which offers 3x?) too.
The machine executor takes a minute or so to start up, but nothing like waiting in line for half an hour for the next VM on Travis.
> In tests/ci-test-wrapper we refer to/mention travis in certain places. Are those sill relevant?
ci-test-wrapper was written in an era when we constantly got "unusual activity"ed on Travis nodes. Basically all it does is to check if there are substantial changes from the previous commit or base branch to warrant a test run.
We later reduced the number of tests, increased gaps, improved robustness, and development settled down, so test skipping is no longer necessary.
When I wrote this PR, I planned for peaceful coexistence with Travis for a while (so I simply set `CI_FORCE_TEST` to bypass Travis-specific checking code). But since Travis is already disabled, I'll clean it up later today.