virtualenv.path_locations() report of lib_dir under pypy

[qwcode]

looks like virtualenv.path_locations() reports wrong lib_dir for current pypy

currently, virtualenv does this:

elif is_pypy:
    lib_dir = home_dir
    inc_dir = join(home_dir, 'include')
    bin_dir = join(home_dir, 'bin')

but take a look at the latest pypy install

bin
include
lib_pypy
lib-python
    2.7
        site.py
        etc..
site-packages

I think lib_dir should do this:

lib_dir = join(home_dir, 'lib-python', py_version)

[pnasrat]

We probably should work out when it changed and have version specific info.

[qwcode]

in looking at this more, I think maybe this was intentional, not just a "bug".
I think it's so the simple action of making site-packages = lib_dir + 'site-packages' can be preserved for pypy.
pypy breaks the mold in that's it's site-packages is right below home.
so not a clear cut bug, but still something to fix.
probably, virtualenv.path_locations() should also report site-packages, in addition to lib_dir, so they can be properly be discriminated.

[pradyunsg]

Is this still unresolved?

[pradyunsg]

virtualenv.path_locations() should also report site-packages, in addition to lib_dir, so they can be properly be discriminated.

@qwcode @pfmoore @dstufft IFAICT, this is a good way to go forward with this; thoughts?

[pfmoore]

I'm reluctant to expand the exposed API of virtualenv. Longer term, I believe people should be moving to the stdlib venv and virtualenv should either disappear (except to support Python 2.x) or become a thin wrapper around venv. To that end, offering any APIs that venv doesn't provide will make that harder.

Surely the canonical way to get site-packages is sysconfig.get_path('purelib') (or platlib...)? I know it involves invoking the target interpreter, but that seems a reasonable constraint to me.

It's conceivable that there is a need for a library to offer a way to introspect aspects of a Python interpreter, without running that interpreter. It's even conceivable that virtualenv might benefit from using such a library. But I don't think we have the resources to maintain such a library as part of virtualenv (especially given the myriad of special cases that exist - Debian's dist-packages, this PyPI variation, Windows vs Unix bin/scripts distinction, etc).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Just add a comment if you want to keep it open. Thank you for your contributions.