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

Update CI for new Python versions #234

Merged
merged 4 commits into from
Jan 3, 2021
Merged

Update CI for new Python versions #234

merged 4 commits into from
Jan 3, 2021

Conversation

nbraud
Copy link
Collaborator

@nbraud nbraud commented Dec 30, 2020

  • Added Python 3.9 environments for Linux and macOS
  • Add Python 3.9 environment for FreeBSD
    That's blocked on the setuptools port being updated to build for 3.9
  • Added missing Python 3.8 environments for FreeBSD and macOS
  • Updated the Python 3.6 and 3.7 envs on macOS to the latest supported by pyenv

@duckinator
Copy link
Owner

Why is pylint giving an incorrect error on the freaking typing module (typing.Optional) of all things. 😂

E: 30,20: Value 'Optional' is unsubscriptable (unsubscriptable-object)

But Optional is from:

from typing import Any, Callable, cast, Dict, Optional, TypeVar

And it's been subscriptable since at least 3.5: https://docs.python.org/3.5/library/typing.html#typing.Optional

@duckinator
Copy link
Owner

Looks like this is pylint-dev/pylint#3882

A fix has been merged on October 9th: pylint-dev/pylint#3890

However, there has not been a Pylint release since then, because of other outsanding Python 3.9-specific bugs.

@duckinator
Copy link
Owner

I think the easiest fix is to fully separate testing and linting, instead of having the test task also do linting on every platform.

@duckinator
Copy link
Owner

@nbraud i'm pushing a change that should fix this by only using pylint and mypy in the linter task.

@duckinator
Copy link
Owner

As a bonus, it gets rid of that kludgey _test-only task I added for FreeBSD. 🙂

@duckinator
Copy link
Owner

Okay, at this point:

  1. The macOS failure is legitimate, but during the install stage.
  2. the Zipapp failure is that pylint bug.

Those are the only failures. I'll throw together a fix for the pylint one (by not running the linter) now.

@nbraud
Copy link
Collaborator Author

nbraud commented Jan 1, 2021

As a bonus, it gets rid of that kludgey _test-only task I added for FreeBSD. slightly_smiling_face

Yay! I had issues with that in #233 too :3

@nbraud nbraud mentioned this pull request Jan 1, 2021
2 tasks
bors bot added a commit that referenced this pull request Jan 1, 2021
235: Fix CI r=nbraud a=nbraud

- [x] Stop running lints when running tests.
      Not only is this inefficient, it forces us to get linting working in all
      environments, which isn't currently possible (see pylint-dev/pylint#3882).
      As a result, remove the `_test-only` task.
- [x] Don't run tests when bootstrapping Bork in CI
      - It is useless, as `python3 /tmp/bork...pyz run test` immediately shells
        out to pytest, and tests the version of bork that is on the filesystem.
      - It fails because `git` isn't installed.

Changes by @duckinator and myself, extracted from #233 and #234

Co-authored-by: Ellen Marie Dash <me@duckie.co>
Co-authored-by: nicoo <nicoo@mur.at>
@nbraud
Copy link
Collaborator Author

nbraud commented Jan 1, 2021

I folded the CI-fixing changes in another PR, and rebased this branch :)

@nbraud
Copy link
Collaborator Author

nbraud commented Jan 1, 2021

@duckinator This works now, and I updated bors.toml to match (I forgot at first) but it seems like you have a bunch of CI steps set manually as “required on github, and some of them (the obsoleted macOS ones) do not exist anymore.

I would suggest setting only “bors” as a required CI step, so we don't have to manually keep the Github repo config in sync with bors.toml and .cirrus.yml.

@duckinator
Copy link
Owner

I set GitHub up to only require bors. 👍

Long-term, I have a rough idea for a nicer way to configure CI stuff — see #236 for details.

@nbraud
Copy link
Collaborator Author

nbraud commented Jan 2, 2021

@duckinator Thanks! <3

Is this good to merge?

@nbraud
Copy link
Collaborator Author

nbraud commented Jan 2, 2021

Rebased to squish the fixup! commit, declared Py3.9 compatibility in setup.cfg.

With those changes in, I believe this PR is good to go.

@duckinator
Copy link
Owner

@nbraud this is good to merge. 🙂

@duckinator
Copy link
Owner

bors r+

@bors bors bot merged commit f329f68 into master Jan 3, 2021
@bors bors bot deleted the py3.9 branch January 3, 2021 00:49
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.

2 participants