types-protobuf fails pre-commit cache #11254
Comments
|
Encountering the same issue as well, this was previously working.... edit: happy to provide logs etc if that helps, but the resulting message I get when I run the edit2: if it helps, I tried using both Python 3.10 and Python 3.11 virtual envs for running the edit3: I cannot find a way to use a "downgraded" of an |
|
Neither #11249, not #11245, the two PRs included in the latest release, should have an influence here. I'm not sure what exactly is going on here, but types-protobuf doesn't add a |
|
Hi @srittau, as I mentioned previously I do know a way to specific specific version within mypy in a pre-commit environment. Using the default though, exhibits the behavior mentioned by the original author. If you know a way to "pin" an additional depency version, let me know and I can test it. |
|
This problem was introduced by typeshed-internal/stub_uploader#109. Previously, the
Cc @Avasam |
|
If I understand correctly, "google" is a namespace package and the In the short term, simply setting In the longer term, we may want a way to identify those so stub_uploader adds the |
|
@Avasam thanks for the explanation, any workarounds for this issue for the interim :-)? |
That's my understanding as well. I think making the necessary changes to the stub_uploader should be fairly simple, although I haven't investigated deeply. |
…le at root Short-term fix for #11254 (see discussion in the issue)
@andylamp Check the very bottom of https://github.com/pre-commit/mirrors-mypy 's readme. I'm pretty sure it's just using pip, so the same markers should work to pin to an older version: |
This is a preliminary refactoring for fixing python/typeshed#11254. The idea is that the new class `PackageData` encapsulates all data concerning packages and their contents. This allows us later to find the top-level non-namespace packages, instead of just the top-level packages as we are doing now.
|
Hi, would it be possible to delete this version from pypi? |
|
I'm not sure who has access to the packages on PyPI. I think @ilevkivskyi could do it. |
|
Also finding all my CI pipelines have broken. In my GitLab CI script I have had to pin it to Any chance this release can be pulled very soon?
|
Stubs are now calendar-versionned, (hence the bump from 4, an index, to 20240106, a date) with the express purpose to communicate that the version number is not semantic (and has never been). There's no such thing as a major/minor/patch/nightly update in typeshed's stubs.
Hopefully? But I'd recommend pinning your libraries versions either way if you want to avoid unexpected CI breakage. Even an update that fixes or improves existing stubs, or an update to type-checkers, could cause your CI to fail all of a sudden (like new false-positives, using new features your type-checker version doesn't support, fixing a false-positive you had suppressed, etc.) |
This is a preliminary refactoring for fixing python/typeshed#11254. The idea is that the new class `PackageData` encapsulates all data concerning packages and their contents. This allows us later to find the top-level non-namespace packages, instead of just the top-level packages as we are doing now.
|
Do you still need me to delete some package from PyPI? If yes, could you please post exactly what is needed (i.e. library and version)? |
|
Hi @ilevkivskyi - For me? I fix the problems with That's (obviously) not a solution to the problem. I have a work-around and I don't have a strong feeling on the topic (it's not my repo) so I'm fine - but it means the latest release can't be used by me (and, I suspect, others) because of the problems it seems to cause with mypy. If someone thinks the problem with types-protobuf is caused by types-protobuf then I guess, yes, pull it. Does someone know what the problem is? |
|
Hi @ilevkivskyi , the removal idea come from me, IMHO if we know that the release is broken and the fix is not coming in hours, then it should be removed: types-protobuf 4.24.0.20240106 |
* build(python): fix `docs` and `docfx` builds Source-Link: googleapis/synthtool@fac8444 Post-Processor: gcr.io/cloud-devrel-public-resources/owlbot-python:latest@sha256:5ea6d0ab82c956b50962f91d94e206d3921537ae5fe1549ec5326381d8905cfa * See googleapis/synthtool#1916 * See python/typeshed#11254 --------- Co-authored-by: Owl Bot <gcf-owl-bot[bot]@users.noreply.github.com> Co-authored-by: Anthonios Partheniou <partheniou@google.com>
* build(python): fix `docs` and `docfx` builds Source-Link: googleapis/synthtool@fac8444 Post-Processor: gcr.io/cloud-devrel-public-resources/owlbot-python:latest@sha256:5ea6d0ab82c956b50962f91d94e206d3921537ae5fe1549ec5326381d8905cfa * See python/typeshed#11254 * See googleapis/synthtool#1916 --------- Co-authored-by: Owl Bot <gcf-owl-bot[bot]@users.noreply.github.com> Co-authored-by: Anthonios Partheniou <partheniou@google.com>
This is a preliminary refactoring for fixing python/typeshed#11254. The idea is that the new class `PackageData` encapsulates all data concerning packages and their contents. This allows us later to find the top-level non-namespace packages, instead of just the top-level packages as we are doing now.
|
Update to those following this issue: with typeshed-internal/stub_uploader#122, the latest version of types-protobuff (4.24.0.20240129) shouldn't have this issue as it doesn't have any The marker file should properly be re-introduced in the subpackages (rather than the root of the namespace package), in a future update to stub_uploader. |
|
This issue should be resolved and we haven't had any new complaints since then. |
when configuring pre-commit mypy to run with
types-protobuf, for example:it fails with the following:
i suspect its related to #11249, but not sure - @AlexWaygood @hauntsaninja i would appreciate your insights here
The text was updated successfully, but these errors were encountered: