Skip to content

Verifytypes diagnostics#46427

Draft
l0lawrence wants to merge 5 commits intoAzure:mainfrom
l0lawrence:verifytypes-diagnostics
Draft

Verifytypes diagnostics#46427
l0lawrence wants to merge 5 commits intoAzure:mainfrom
l0lawrence:verifytypes-diagnostics

Conversation

@l0lawrence
Copy link
Copy Markdown
Member

No description provided.

scbedd and others added 5 commits April 20, 2026 19:16
- Wrap git steps in _run_git helper that captures stderr (previously
  stderr was merged into stdout and piped to DEVNULL, hiding failures).
- Capture and log stdout/stderr from the 'pip install .' step of the
  main-branch install; raise CalledProcessError on failure so real
  install errors surface as a CI failure instead of being treated as
  'package not in main, skip'.
- Add --no-deps to the main-branch install so pyright sees the same
  dependency closure for both type-completeness runs, isolating the
  comparison to changes in the package itself.
- Use as_posix() for the sparse-checkout path.

Relates to Azure#46426.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
When pyright --verifytypes completes but produces empty output, the
common root cause is that the installed package is missing namespace
__init__.py files or was installed to an unexpected location — pyright
finds zero symbols and exits 1 silently.

Add a _log_installed_package_layout helper that runs 'pip show -f' for
the distribution and walks the on-disk module directory via
importlib.util.find_spec. This makes the empty-pyright-output case
diagnosable from CI logs without having to reproduce locally.

Relates to Azure#46426.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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