Installing pypy3 failed with "Error: IS_WINDOWS is not defined" #171
Labels
bug
Something isn't working
Comments
|
Since this just started happening, I'm guessing it's a regression in the 2.2.0 release. |
|
It also looks like this project's own CI is impacted by this: https://github.com/actions/setup-python/runs/1571081954?check_suite_focus=true |
|
Same error for PyPy2. |
|
Same error on my projects. |
|
Same error here, only on pypy2 and pypy3. Other python versions are unaffected. |
|
Same here for pypy2 and pypy3. |
This was referenced Dec 17, 2020
1 task
3 tasks
This was referenced Dec 18, 2020
altendky
added a commit
to twisted/python-info-action
that referenced
this issue
Dec 18, 2020
Cielquan
added a commit
to Cielquan/python_test-cielquan
that referenced
this issue
Dec 18, 2020
Cielquan
added a commit
to Cielquan/python_test-cielquan
that referenced
this issue
Dec 18, 2020
|
Hello everyone! As a workaround, I suggest using new syntax for PyPy: See more examples in https://github.com/actions/setup-python#specifying-a-pypy-version 2.2.0 release was directed to add support for new PyPy syntax to allow installing PyPy on-flight and specifying exact version. But looks like we got regression in old syntax: #169 |
thisiscam
added a commit
to thisiscam/math-with-slack
that referenced
this issue
Dec 18, 2020
FIx CI pypy versioning as suggested in actions/setup-python#171
Merged
8 tasks
icemac
pushed a commit
to zopefoundation/meta
that referenced
this issue
Dec 18, 2020
jamadden
added a commit
to gevent/gevent
that referenced
this issue
Dec 18, 2020
|
The new There was a small merge conflict between multiple PRs related to webpack and |
Andrew-Chen-Wang
referenced
this issue
in aio-libs-abandoned/aioredis-py
Dec 18, 2020
Add Windows to GitHub Action CI
|
Thanks for the rapid turnaround, everyone. You rock... as always. |
leycec
added a commit
to beartype/beartype
that referenced
this issue
Dec 19, 2020
This commit adds support for the PEP 484-compliant `None` singleton, which we only belatedly realized we'd accidentally failed to support. Better late than never, right? Right? *sigh* Unrelatedly, this commit also resolves the upstream actions/setup-python#171 issue currently blocking GitHub Actions-based continuous integration (CI) as well as continuing to revise our front-facing `README.rst` for consistency, clarity, and PEP-compliance. ## Compatibility Improved * **[PEP 484-compliant `None` singleton](https://www.python.org/dev/peps/pep-0484/#id16).** `@beartype` now implicitly reduces the `None` singleton at all nesting levels of type hints to that singleton's type per PEP 484. ## Tests Improved * **PyPy 3.7 exercised under CI.** Our `tox` and GitHub Actions-based continuous integration (CI) configurations now both correctly exercise themselves against both PyPy 3.6 and 3.7, resolving the upstream actions/setup-python#171 issue for `@beartype`. (*Burdensome urges surge tempestuous distempers!*)
leycec
added a commit
to beartype/beartype
that referenced
this issue
Mar 4, 2021
This release brings explicit support for ``None``, subscripted generics, and PEP 561 compliance. This release resolves **10 issues** and merges **8 pull requests.** Specific changes include: ## Compatibility Improved * **[PEP 484-compliant `None` singleton](https://www.python.org/dev/peps/pep-0484/#id16).** As a return type hint, `None` is typically used to annotate callables containing *no* explicit `return` statement and thus implicitly returning `None`. `@beartype` now implicitly reduces `None` at all nesting levels of type hints to that singleton's type per [PEP 484](https://www.python.org/dev/peps/pep-0484/#id16). * **[PEP 561 compliance](https://www.python.org/dev/peps/pep-0561).** `beartype` now fully conforms to [PEP 561](https://www.python.org/dev/peps/pep-0561), resolving issue #25 kindly submitted by best macOS package manager ever @harens. In useful terms, this means that: * **`beartype` now complies with [mypy](http://mypy-lang.org),** Python's popular third-party static type checker. If your package had no [mypy](http://mypy-lang.org) errors or warnings *before* adding `beartype` as a mandatory dependency, your package will still have no [mypy](http://mypy-lang.org) errors or warnings *after* adding `beartype` as a mandatory dependency. * **`beartype` preserves [PEP 561](https://www.python.org/dev/peps/pep-0561) compliance.** If your package was [PEP 561-compliant](https://www.python.org/dev/peps/pep-0561) *before* adding `beartype` as a mandatory dependency, your package will still be [PEP 561-compliant](https://www.python.org/dev/peps/pep-0561) *after* adding `beartype` as a mandatory dependency. Of course, if your package currently is *not* [PEP 561-compliant](https://www.python.org/dev/peps/pep-0561), `beartype` can't help you there. We'd love to, really. [It's us. Not you.](https://www.youtube.com/watch?v=2uAj4wBIU-8) * **The `beartype` codebase is now mostly statically rather than dynamically typed,** much to our public shame. Thus begins the eternal struggle to preserve duck typing in a world that hates bugs. * **The `beartype` package now contains a top-level `py.typed` file,** publicly declaring this package to be [PEP 561-compliant](https://www.python.org/dev/peps/pep-0561). * **Subscripted generics** (i.e., [user-defined generics](https://www.python.org/dev/peps/pep-0484) subscripted by one or more type hints), resolving issue #29 kindly submitted by indefatigable test engineer and anthropomorphic Siberian Husky @eehusky. Since it's best not to ask too many questions about subscripted generics, we instead refer you to [the issue report that nearly broke a Canadian man](#29). ## Compatibility Broken * **None.** This release preserves backward compatibility with the prior stable release. ## Packaging Improved * **New optional installation-time extras,** enabling both `beartype` developers and automation tooling to trivially install recommended (but technically optional) dependencies. These include: * `pip install -e .[dev]`, installing `beartype` in editable mode as well as all dependencies required to both locally test `beartype` *and* build documentation for `beartype` from the command line. * `pip install beartype[doc-rtd]`, installing `beartype` as well as all dependencies required to build documentation from the external third-party Read The Docs (RTD) host. * **Homebrew- and MacPorts-based macOS installation.** Our front-facing `README.rst` file now documents `beartype` installation with both Homebrew and MacPorts on macOS, entirely courtesy the third-party Homebrew tap and Portfile maintained by build automation specialist and mild-mannered student @harens. Thanks a London pound, Haren! ## Features Added * Public `beartype.cave` types and type tuples, including: * `beartype.cave.CallableCTypes`, a tuple of all **C-based callable types** (i.e., types whose instances are callable objects implemented in low-level C rather than high-level Python). * `beartype.cave.HintGenericSubscriptedType`, the C-based type of all subscripted generics if the active Python interpreter targets Python >= 3.9 *or* `beartype.cave.UnavailableType` otherwise. This type was previously named `beartype.cave.HintPep585Type` before we belatedly realized this type broadly applies to numerous categories of PEP-compliant type hints, including PEP 484-compliant subscripted generics. ## Features Optimized * **`O(n)` → `O(1)` exception handling.** `@beartype` now internally raises human-readable exceptions in the event of type-checking violations with an `O(1)` rather than `O(n)` algorithm, significantly reducing time complexity for the edge case of invalid large sequences either passed to or returned from `@beartype`-decorated callables. For forward compatibility with a future version of `beartype` enabling users to explicitly switch between constant- and linear-time checking, the prior `O(n)` exception-handling algorithm has been preserved in a presently disabled form. * **`O(n)` → `O(1)` callable introspection during internal memoization.** `@beartype` now avoids calling the inefficient stdlib `inspect` module from our private `@beartype._util.cache.utilcachecall.callable_cached` decorator memoizing functions throughout the `beartype` codebase. The prior `O(n)` logic performed by that call has been replaced by equivalent `O(1) logic performed by a call to our newly defined `beartype._util.func.utilfuncarg` submodule, optimizing function argument introspection without the unnecessary overhead of `inspect`. * **Code object caching.** `@beartype` now temporarily caches the code object for the currently decorated callable to support efficient introspection of that callable throughout the decoration process. Relatedly, this also has the beneficial side effect of explicitly raising human-readable exceptions from the `@beartype` decorator on attempting to decorate C-based callables, which `@beartype` now explicitly does *not* support, because C-based callables have *no* code objects and thus *no* efficient means of introspection. Fortunately, sane code only ever applies `@beartype` to pure-Python callables anyway. ...right, sane code? *Right!?!?* ## Features Deprecated * The ambiguously named `beartype.cave.HintPep585Type` type, to be officially removed in `beartype` 0.1.0. ## Issues Resolved * **Unsafe `str.replace()` calls.** `@beartype` now wraps all unsafe internal calls to the low-level `str.replace()` method with calls to the considerably safer high-level `beartype._util.text.utiltextmunge.replace_str_substrs()` function, guaranteeing that memoized placeholder strings are properly unmemoized during decoration-time code generation. Thanks to temperate perennial flowering plant @Heliotrop3 for this astute observation and resolution to long-standing background issue #11. * **`KeyPool` release validation.** `@beartype` now validates that objects passed to the `release()` method of the private `beartype._util.cache.pool.utilcachepool.KeyPool` class have been previously returned from the `acquire()` method of that class. Thanks to @Heliotrop3, the formidable bug assassin, for their unswerving dedication to the cause of justice with this resolution to issue #13. * **Least Recently Used (LRU) cache.** ``@beartype`` now internally provides a highly microoptimized Least Recently Used (LRU) cache for subsequent use throughout the codebase, particularly with respect to caching iterators over dictionaries, sets, and other non-sequence containers. This resolves issue #17, again graciously submitted by open-source bug mercenary @Heliotrop3. * **Callable labelling.** `@beartype` now internally provides a private `beartype._util.func.utilfuncorigin.get_callable_origin_label` getter synthesizing human-readable labels for the files declaring arbitrary callables, a contribution by master code-mangler @Heliotrop3 resolving issue #18. Thanks again for all the insidious improvements, Tyler! You are the master of everyone's code domain. * **Release automation.** Our release workflow has now been migrated from the unmaintained `create-release` GitHub Action to @ncipollo's actively maintained `release-action`, resolving issue #22 kindly submitted by human-AI-hybrid @Heliotrop3. ## Tests Improved * **Microsoft Windows and macOS exercised under CI**, resolving issue #21. Since doing so increases our consumption of Microsoft resources that we care deeply about, care has been taken to reduce the cost of our CI workflow. This includes: * Replacing our prior use of the external third-party `tox-gh-actions` GitHub Action streamlining `tox` usage with our own ad-hoc build matrix that appears to be simpler and faster despite offering basically identical functionality. * Removing our prior installation of optional dependencies, especially including NumPy. *Yeah.* Let's not do that anymore. Thanks to dedicated issue reporter @Heliotrop3 for his unsustainable deep-code trawling of the `beartype` codebase for unresolved `FIXME:` comments. * **PyPy 3.7 exercised under CI.** Our `tox` and GitHub Actions-based continuous integration (CI) configurations now both correctly exercise themselves against both PyPy 3.6 and 3.7, resolving the upstream actions/setup-python#171 issue for `beartype`. * **CI thresholded.** Our CI configuration now caps tests to a sane maximum duration of time to avoid a repeat of the pull request we do *not* talk about here. Okay, it was #23. I blame only myself. * **New functional tests,** including: * A **CPython-specific [mypy](http://mypy-lang.org) functional test,** optionally exercising our conformance to static type-checking standards when the third-party `mypy` package is installed under CPython. This test is sufficiently critical that we perform it under our CI workflow, guaranteeing test failures on any push or PR violating mypy expectations. * A **`README.rst` functional test,** optionally exercising the syntactic validity of our front-facing `README.rst` documentation when the third-party `docutils` package (i.e., the reference reST parser) is installed. This test is sufficiently expensive that we currently avoid performing it under our CI workflow. * **New unit tests,** including: * **Text munging unit tests,** exercising the private `beartype._util.text.utiltextmunge` submodule with lavish attention to regex-based fuzzy testing of the critical `number_lines()` function. Humble `git log` shout outs go out to @Heliotrop3 for this mythic changeset that warps the fragile fabric of the GitHub cloud to its own pellucid yet paradoxically impenetrable intentions, resolving issue #24. ## Documentation Revised * **Sphinx skeleton.** The `beartype` repository now defines a largely unpopulated skeleton for Sphinx-generated documentation formatted as reST and typically converted to HTML to be hosted at [Read The Docs (RTD)](https://beartype.readthedocs.io/en/latest/?badge=latest), generously contributed by @felix-hilden, Finnish computer vision expert and our first contributor! This skeleton enables: * An HTTP 404 redirect page on missing page hits. * The standard retinue of builtin Sphinx extensions (e.g., `autodoc`, `viewcode`). * MathJax configured for remote implicit downloads. * Napolean configured for NumPy-formatted docstrings. * An optional dependency on `sphinx_rtd_theme`, a third-party Sphinx extension providing RTD's official Sphinx HTML. * A **badge** (i.e., shield, status icon) on our front-facing `README.rst` documentation signifying the success of the most recent attempt to build and host this skeleton at RTD. * A **top-level `sphinx` script**, building Sphinx-based package documentation when manually run from the command line by interactive developers. * A **[beautiful banner graphic that makes grown adults openly weep](https://github.com/beartype/beartype-assets/tree/main/banner),** featuring the official `beartype` mascot "Mr. Nectar Palm" – again courtesy @felix-hilden, because sleep is for the weak and Felix has never known the word. * A **new prefacing "tl;dr" section** that's redundant with numerous other sections, but we're surprisingly okay with that. * A **new "Usage" section** that accidentally became a new tutorial and division of the existing "Overview" section into various subsections highlighting tradeoffs between `beartype` and existing type checkers, resolving clarity concerns raised by @kevinjacobs-progenity at issue #7. Thanks for the invaluable commentary, Kevin! * A **new "Frequently Asked Questions (FAQ)" section,** inspired by the admission from several prospective users that they have utterly no idea what @leycec is talking about. Fair play, users. You win this round. * A **new "Workflow" subsection of the "Developer" section,** listing developer-specific instructions for forking, cloning, installing, modifying, and submitting PRs for `beartype` in a live manner. * **Properly rendered code blocks,** kindly reported by humane human extraordinaire @harens in discussion topic #28. Thanks and may the little-seen English sun eternally shine upon ye, Haren! ## API Changed * Added: * `beartype.cave.CallableCTypes`. * `beartype.cave.HintGenericSubscriptedType`. * Deprecated: * `beartype.cave.HintPep585Type`. (*Exogenous exhaustion!*)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
https://github.com/pyca/cryptography/pull/5652/checks?check_run_id=1571744687
->
Which version of the action are you using?
v1v2v2.0.1ormaster)Environment
If applicable, please specify if you're using a container
Python Versions
pypy3Run/Repo Url
https://github.com/pyca/cryptography/pull/5652/checks?check_run_id=1571744687
The text was updated successfully, but these errors were encountered: