Open P403n1x87 opened 3 years ago
Duplicate of https://github.com/python/mypy/issues/4380 but that user seems to have been fine with using a virtualenv. It seems that you are using prefix inside a venv already. Is there a reason you can't put the virtualenv in the prefix you want?
The reason is that we have a nested data structure that describes Python packages that need to be installed at each nesting level. Deeper levels should override the previous ones, so the packages are installed in a specific prefix at each level. The root level represents the base virtual env and nothing gets installed in the default prefix, so this is why mypy
is installed in a non-default prefix even at the first level after root. If we wanted to install mypy
in the default prefix we would have to hard-code a specific rule for it, which would be a bit awkward.
Hm, I'm not sure I entirely understand your use case, but why can't you just install mypy and other tools in separate venvs and execute them like venv/bin/mypy
?
Otherwise, if you would like to propose a change that would fix mypy with --prefix, I will review it.
why can't you just install mypy and other tools in separate venvs and execute them like
venv/bin/mypy
?
We can of course and that's more or less what we currently do, but we were hoping to reduce the number of venvs we generate as we only need one if we use prefixes and judiciously set the PYTHONPATH
and PATH
. This optimisation would save us memory and time in CI.
If it helps, this is the kind of structure that we have
Venv(
pys=["3.8"],
name="foo",
pkgs={
"pytest": latest # this is just an example
},
venvs=[
Venv(
name="bar",
command="mypy --install-types --non-interactive .",
pkgs={
"mypy": ["==0.900", latest]
},
),
],
)
This generates two venv instances where we have a common "layer" with just pytest
and two layers with mypy==0.900
and mypy
respectively on top. These dependencies are installed in their own prefixes inside a 3.8 venv. Currently, we generate all the intermediate venvs that require packages and activate the leaf ones, but by setting the PYTHONPATH
and PATH
we could use just the base one, thus saving memory and time.
@ethanhs I have opened #10833 and would love some feedback to see if that's going in the right direction. If it's looking good, I would also appreciate some guidelines for adding a test case. This would require installing mypy
outside the default prefix.
Bug Report
Let me introduce some shorthand notation for the sake of clarity. Let
V
be a virtual environment,Vsp
thesite-packages
location withinV
,P
a prefix path andPsp
thesite-packages
location withinP
.Now suppose that
mypy
is installed inP
withpip install --prefix P mypy
from withinV
. When invokingmypy
fromV
, withmypy --install-types
, the missing types are installed inVsp
, and this leads to errors of the kind(note that when
mypy
is installed inV
rather than inP
, no errors are reported, as expected). SettingMYPYPATH
to includeVsp
giveswhich is documented behaviour. Installing the missing types by hand in
P
fromV
withpip install --prefix type-...
doesn't help:Setting
MYPYPATH
to includePsp
givesSo there doesn't seem to be a way to install
mypy
in a prefixTo Reproduce
See the above description of the issue
Expected Behavior
I would expect
mypy
to work even if I'd have to setMYPYPATH
to somethingActual Behavior
No possible way of using
mypy
from a custom prefix.Your Environment
--install-types --non-interactive
mypy.ini
(and other config files):