Not possible to build and install mypy with mypyc support, and run the tests against it.

[eli-schwartz]

mypy's built wheels includes two installable packages available after mypy is fully installed. They appear to not be practically usable:

• import mypy.test
• import mypyc.test

The testsuite depends on conftest.py and pyproject.toml from the root of the repository to run. Also, the test-data/ directory provides data the tests need. None of this data is distributed in the built wheels.

The fact that the packages are installed at all appears to be a bug. This is a side effect of #2784 which requested that the sdist (not the wheel) include the testsuite so that redistributors such as Debian can run the tests when packaging.

The intertwining of the testsuite as part of the mypy module alongside the requirement to use data from the sources makes it difficult to test mypy correctly. Allowing the tests to be detected by pytest means making the mypy/ directory importable and causes the tests to incorrectly run against the pure-python version, which means the compiled extensions do not get tested.

And mypy's own CI is working around this with editable installs:

mypy/.github/workflows/test.yml

Lines 137 to 145 in 9b91524

	- name: Compiled with mypyc
	if: ${{ matrix.test_mypyc }}
	run: |
	pip install -r test-requirements.txt
	CC=clang MYPYC_OPT_LEVEL=0 MYPY_USE_MYPYC=1 pip install -e .
	- name: Setup tox environment
	run: tox run -e ${{ matrix.toxenv }} --notest
	- name: Test
	run: tox run -e ${{ matrix.toxenv }} --skip-pkg-install -- ${{ matrix.tox_extra_args }}

Also, the installation footprint of these unused files seems to be a couple of MB, which could be a nice optimization...

[bzoracler]

mypy.test contains a substantial amount of code for test case parsing (of *.test files) and pytest test discovery, and (with some API wrapping) the code is usable for unit-testing both standard static typing and also mypy plugins.

As there doesn't appear to be any guidelines for whether we should avoid writing *.test files and using the mypy.test package in third-party code, some of us may have used it to develop testing suites; I'm personally relying on mypy.test to parse files like check-incremental.test, as I'm not aware of any elegant alternatives to testing mypy plugins in incremental mode.

If mypy.test is no longer distributed, unless it is pulled out into a standalone and installable package, some of us will end up having to duplicate and maintain a copy of mypy's test parsing and discovery code.

[hauntsaninja]

Thanks for chiming in bzoracler, always useful to know what people are depending on. I think when mypy tests its own mypyc based wheel builds, we use the MYPY_TEST_PREFIX to solve this: https://github.com/mypyc/mypy_mypyc-wheels/blob/c45eabde33a072aa45ae2e7789e485ec0ffb05fd/cibuildwheel.toml#L34

[eli-schwartz]

# pytest looks for configuration files in the parent directories of where the tests live. since we are trying to run the tests from their installed location, we copy those into the venv. Ew ew ew.

@hauntsaninja thanks for the link. It looks like if this ticket can be resolved somehow, it would solve more than one problem, then.