[BUG] unable to do a local install with pyproject.toml in a venv, created with --system-site-packages #3240

skirpichev · 2022-04-02T04:09:34Z

setuptools version

61.3.1

Python version

3.10

OS

Debian Linux

Additional environment information

No response

Description

Initially reported here. Local installation of the package doesn't work in the venv, created with --system-site-packages.

The example of package:

$ cat -n xxx/pyproject.toml
     1  [build-system]
     2  requires = ['pip>=20.3', 'setuptools>=61']
     3  build-backend = 'setuptools.build_meta'
     4  
     5  [project]
     6  name = 'spam'
     7  version = '1.0'
$ cat -n xxx/spam/__init__.py
     1  def foo(x):
     2      return x + 1

Expected behavior

There should be no difference wrt presence of the --system-site-packages option.

How to Reproduce

$ python3.10 -m venv --system-site-packages ~/venv/xxx
$ . ~/venv/xxx/bin/activate
$ cd ~/xxx
$ pip install -U pip setuptools # ok
$ pip install .  # reports Successfully installed UNKNOWN-0.0.0
$ cd ..
$ python -c 'from spam import foo; print(foo(1))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'spam'

Output

$ pip install .
Processing /home/sk/xxx
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Installing backend dependencies ... done
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: UNKNOWN
  Building wheel for UNKNOWN (pyproject.toml) ... done
  Created wheel for UNKNOWN: filename=UNKNOWN-0.0.0-py3-none-any.whl size=961 sha256=bdf45535227b14dd48575543b53abf23a2cf3f3b8832b990179317afb6cdf399
  Stored in directory: /tmp/pip-ephem-wheel-cache-axtp8tef/wheels/10/53/d2/68b61cf7b7b3877818736cb5972843b90ae1ee8528e73f359e
Successfully built UNKNOWN
Installing collected packages: UNKNOWN
Successfully installed UNKNOWN-0.0.0

The text was updated successfully, but these errors were encountered:

abravalheri · 2022-04-02T09:34:43Z

Hi @skirpichev, after some investigation it seems that setuptools is being loaded from a different location in the disk instead of the virtualenv. But only for Debian-based installations:

This is what I learned so far:

A. We can replicate the problem in a Debian installation (docker run --rm -it python:3.10-bullseye /bin/bash)

Create the package

mkdir /tmp/proj
cd /tmp/proj
cat <<EOS > pyproject.toml
[build-system]
requires = ['pip>=20.3', 'setuptools>=61']
build-backend = 'setuptools.build_meta'
 
[project]
name = 'spam'
version = '1.0'
EOS
mkdir spam
touch spam/__init__.py

Create the virtual environment:

python3 -m venv --system-site-packages .venv

Run the installation and observe the error:

.venv/bin/python -m pip install -U pip setuptools
.venv/bin/python -m pip install .
# => Successfully installed UNKNOWN-0.0.0

B. This error is caused by setuptools being loaded from outside the virtual environment.

To get evidence about it we can do:

Remove the .pth file from the virtual environment to make sure this is not caused by the distutils modernizing workaround
```
rm .venv/lib/python3.10/site-packages/*.pth
```

Let's break the system installation of setuptools on purpose. If the version of setuptools is loaded from the virtual environment, we should not see any error

apt update && apt install -y vim
vim /usr/local/lib/python3.10/site-packages/setuptools/build_meta.py
# add `raise ValueError("setuptools loaded from the wrong place")`
# as the first instruction inside `def get_requires_for_build_wheel`

Run pip again and observe the error:

.venv/bin/python -m pip install .
Processing /tmp/proj
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  error: subprocess-exited-with-error

  × Getting requirements to build wheel did not run successfully.
  │ exit code: 1
  ╰─> [10 lines of output]
      Traceback (most recent call last):
        File "/tmp/proj/.venv/lib/python3.10/site-packages/pip/_vendor/pep517/ in_process/_in_process.py", line 363, in <module>
          main()
        File "/tmp/proj/.venv/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 345, in main
         json_out['return_val'] = hook(**hook_input['kwargs'])
        File "/tmp/proj/.venv/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 130, in get_requires_for_build_wheel
         return hook(config_settings)
        File "/usr/local/lib/python3.10/site-packages/setuptools/build_meta.py", line 153, in get_requires_for_build_wheel
          raise ValueError("setuptools loaded from the wrong place")
      ValueError: setuptools loaded from the wrong place
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× Getting requirements to build wheel did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

C. Repeat the process A but in a fedora container (docker run --rm -it fedora)

Observe the build succeed: Successfully installed spam-1.0

So far it does not look to me that this problem is particularly caused by version 61, but rather by how setuptools is being loaded by the installer.

abravalheri · 2022-04-02T09:46:13Z

I don't know if this is related to https://sources.debian.org/src/python3.10/3.10.4-2/Lib/_distutils_system_mod.py/ somehow.

skirpichev · 2022-04-02T09:59:01Z

But only for Debian-based installations

Hmm, I don't think it's a Debian-specific problem. In fact, the used python3.10 binary (I use the stable, i.e. bullseye - and it has CPython 3.9, not 3.10!) was locally-built (./confiqure -q && make -s && make -s install :)) So, if there are Debian-specific patches for the distutils stuff - I doubt they were applied. The binary was rebuilt recently:

$ python3.10 --version
Python 3.10.2+
$ ls -l `which python3.10`
-rwxr-xr-x 1 sk staff 22M Feb 19 07:14 /usr/local/bin/python3.10

Sorry for an incomplete bugreport, I hope this helps.

abravalheri · 2022-04-02T10:13:40Z

I am replicating the bug of from where setuptools is being loaded even with version 60.9.3.
The best would be replicate this issue with a distribution that is not debian based, this way we can ensure that is not being caused by any setuptools patch.

abravalheri · 2022-04-02T10:16:30Z

These are the steps to replicate the problem with 60.9.3:

> docker run --rm -it python:3.10-bullseye /bin/bash

mkdir /tmp/proj
cd /tmp/proj
cat <<EOS > pyproject.toml
[build-system]
requires = ['setuptools==60.9.3']
build-backend = 'setuptools.build_meta'
EOS
python3 -m venv --system-site-packages .venv
.venv/bin/python -m pip install -U pip 'setuptools==60.9.3'

# Let's make the global setuptools broken on purpose

sed -i '/def get_requires_for_build_wheel/a\        raise SystemError("setuptools loaded from /usr", setuptools.__version__)' /usr/local/lib/python3.10/site-packages/setuptools/build_meta.py

.venv/bin/python -m pip install .

Processing /tmp/proj
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  error: subprocess-exited-with-error

  × Getting requirements to build wheel did not run successfully.
  │ exit code: 1
  ╰─> [10 lines of output]
      Traceback (most recent call last):
        File "/tmp/proj/.venv/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 363, in <module>
          main()
        File "/tmp/proj/.venv/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 345, in main
          json_out['return_val'] = hook(**hook_input['kwargs'])
        File "/tmp/proj/.venv/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 130, in get_requires_for_build_wheel
          return hook(config_settings)
        File "/usr/local/lib/python3.10/site-packages/setuptools/build_meta.py", line 153, in get_requires_for_build_wheel
          raise SystemError("setuptools loaded from /usr", setuptools.__version__)
      SystemError: ('setuptools loaded from /usr', '58.1.0')
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× Getting requirements to build wheel did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

abravalheri · 2022-04-02T11:58:52Z

I can confirm the same error for alpine. I ran the same example as above via:

docker run --rm -it python:3.10-alpine3.14 /bin/ash

The error persists even if we do the following:

# Make sure manipulations of the PYTHONPATH are not used in the virtual environment
rm -rf .venv/lib/python3.10/site-packages/*.pth
# Let's add a `setup.cfg` just in case
cat <<EOS > setup.cfg
[metadata]
name = proj
version = 42
EOS

Alpine Linux does not rely on a specific hook: _distutils_system_mod.py.

abravalheri · 2022-04-02T12:02:36Z

@skirpichev, I am not sure if there is any action point for setuptools here.

I don't know how venv works internally with --system-site-packages, maybe this is expected?
I also don't know how pip and pep517 interact with that configuration in the virtual environment.

abravalheri · 2022-04-02T12:14:59Z

If you want to report this problem to the other related tools, I recommend the following reproducer:

docker run --rm -it python:3.10-alpine3.14 /bin/ash
# OR
# docker run --rm -it python:3.10-bullseye /bin/bash

mkdir /tmp/proj
cd /tmp/proj
cat <<EOS > pyproject.toml
[build-system]
requires = ['setuptools==60.9.3']
build-backend = 'setuptools.build_meta'
EOS
cat <<EOS > setup.cfg
[metadata]
name = proj
version = 42
EOS
python3 -m venv --system-site-packages .venv
.venv/bin/python -m pip install -U pip 'setuptools==60.9.3'

# Let's make the global setuptools broken on purpose

sed -i '/def get_requires_for_build_wheel/a\        raise SystemError("setuptools loaded from /usr", setuptools.__version__)' /usr/local/lib/python3.10/site-packages/setuptools/build_meta.py

.venv/bin/python -m pip install .

Processing /tmp/proj
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  error: subprocess-exited-with-error

  × Getting requirements to build wheel did not run successfully.
  │ exit code: 1
  ╰─> [10 lines of output]
      Traceback (most recent call last):
        File "/tmp/proj/.venv/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 363, in <module>
          main()
        File "/tmp/proj/.venv/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 345, in main
          json_out['return_val'] = hook(**hook_input['kwargs'])
        File "/tmp/proj/.venv/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 130, in get_requires_for_build_wheel
          return hook(config_settings)
        File "/usr/local/lib/python3.10/site-packages/setuptools/build_meta.py", line 153, in get_requires_for_build_wheel
          raise SystemError("setuptools loaded from /usr", setuptools.__version__)
      SystemError: ('setuptools loaded from /usr', '58.1.0')
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× Getting requirements to build wheel did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

Personally, I would expect setuptools to be loaded from .venv.
Clearly this expectation is not being fulfilled.
I don't know if this behaviour is intentionally triggered by --system-site-packages.

skirpichev · 2022-04-02T12:54:10Z

Sorry, I doubt this should be silently closed. There was no difference before introducing support for the pyproject.toml.

Please reconsider.

abravalheri · 2022-04-02T12:56:34Z

Hi @skirpichev, thanks for the feedback.

I will reopen the issue, but I don't see what can be done in setuptools.

There was no difference before introducing support for the pyproject.toml.

The example in #3240 (comment) shows the opposite doesn't it? According to that example, setuptools is being loaded from outside of the virtual environment even before v61.

What would be your suggestion?

skirpichev · 2022-04-03T01:53:24Z

The example in #3240 (comment) shows the opposite doesn't it?

I didn't get it. You break something, right?

But if you don't, both variants (with and without options) - work for me with the old setuptools versions.

$ python3.10 -m venv --system-site-packages ~/venv/xxx
$ cd xxx
$ cat -n pyproject.toml 
     1  [build-system]
     2  requires = ['pip>=20.3', 'setuptools==58']
     3  build-backend = 'setuptools.build_meta'
$ cat -n setup.cfg 
     1  [metadata]
     2  name = spam
     3  version = 1.0
     4  [options]
     5  packages = find:
$ cat -n spam/__init__.py 
     1  def foo(x):
     2      return x + 1
$ pip install -U pip 'setuptools==58'  # ok
$ pip install .
Processing /home/sk/xxx
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Installing backend dependencies ... done
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: spam
  Building wheel for spam (pyproject.toml) ... done
  Created wheel for spam: filename=spam-1.0-py3-none-any.whl size=1115 sha256=b0427afa96e7cb5777fe00940116ee67bbdb7740a5365750e6893ea76e85da7c
  Stored in directory: /tmp/pip-ephem-wheel-cache-_yswembv/wheels/10/53/d2/68b61cf7b7b3877818736cb5972843b90ae1ee8528e73f359e
Successfully built spam
Installing collected packages: spam
  Attempting uninstall: spam
    Found existing installation: spam 1.0
    Uninstalling spam-1.0:
      Successfully uninstalled spam-1.0
Successfully installed spam-1.0
$ cd
$ python -c 'from spam import foo; print(foo(1))'
2

Unless I miss something, the above configuration is an equivalent for the original version from the bugreport. The differences are: using setup.cfg for the project info and the old setuptools version, of course. In fact, the latter doesn't matter: you can drop the harcoded setuptools version and use 61.3.1. The thing that does create the difference in behaviour for different venv's - is using the pyproject.toml for the project info.

Maybe it's an accident that is was working this way. But it was so for years...

What would be your suggestion?

So far - removing the invalid label:)

Probably, both configs (with and without using the pyproject.toml for the project info) - should work in a same way for any given virtual environment. E.g. fail both if the --system-site-packages option was present.

abravalheri · 2022-04-03T08:30:00Z

I didn't get it. You break something, right?
But if you don't, both variants (with and without options) - work for me with the old setuptools versions.

The fact that it works is a coincidence between the version that you have installed system-wide in your machine (outside of the virtual environment) and the feature you need.

Somehow the installer/front-end is loading setuptools from outside the virtual environment.
When the "global" installation of setuptools does not match the version you require, that might lead to bugs.

Let's illustrate this problem once more:

A. Create a project with a specific version of setuptools. Set a virtual environment that fulfils the build dependencies.

> docker run --rm -it python:3.10-alpine3.14 /bin/ash

mkdir /tmp/proj
cd /tmp/proj
cat <<EOS > pyproject.toml
[build-system]
requires = ['setuptools==47']
build-backend = 'setuptools.build_meta'
EOS
python3 -m venv --system-site-packages .venv
.venv/bin/python -m pip install -U pip 'setuptools==47'

Here I choose setuptools 47 because it is a version that does not try to mess with .pth files:

.venv/bin/python3 -c 'import setuptools; print(setuptools.__version__)'
# 47.0.0
ls .venv/lib/python3.10/site-packages/*.pth  
# ls: .venv/lib/python3.10/site-packages/*.pth: No such file or directory

B. Install an older version of setuptools in the system wide Python installation (outside of the virtual environment)

python3 -m pip uninstall -y setuptools
python3 -m pip install 'setuptools==39'

# Meanwhile the version inside the virtual environment exists and has the correct version
.venv/bin/python -c 'import setuptools; print(setuptools.__version__)'
# 47.0.0

C. Run the installation and see it failing because it is loading the version of setuptools from outside the virtual environment.

.venv/bin/python -m pip install .
Processing /tmp/proj
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  error: subprocess-exited-with-error

  × Getting requirements to build wheel did not run successfully.
  │ exit code: 1
  ╰─> [38 lines of output]
      Traceback (most recent call last):
        File "/tmp/proj/.venv/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 363, in <module>
          main()
        File "/tmp/proj/.venv/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 345, in main
          json_out['return_val'] = hook(**hook_input['kwargs'])
        File "/tmp/proj/.venv/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 124, in get_requires_for_build_wheel
          backend = _build_backend()
        File "/tmp/proj/.venv/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 89, in _build_backend
          obj = import_module(mod_path)
        File "/usr/local/lib/python3.10/importlib/__init__.py", line 126, in import_module
          return _bootstrap._gcd_import(name[level:], package, level)
        File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
        File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
        File "<frozen importlib._bootstrap>", line 992, in _find_and_load_unlocked
        File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
        File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
        File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
        File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
        File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
        File "<frozen importlib._bootstrap_external>", line 883, in exec_module
        File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
        File "/usr/local/lib/python3.10/site-packages/setuptools/__init__.py", line 12, in <module>
          import setuptools.version
        File "/usr/local/lib/python3.10/site-packages/setuptools/version.py", line 1, in <module>
          import pkg_resources
        File "/usr/local/lib/python3.10/site-packages/pkg_resources/__init__.py", line 77, in <module>
          __import__('pkg_resources.extern.packaging.requirements')
        File "/usr/local/lib/python3.10/site-packages/pkg_resources/_vendor/packaging/requirements.py", line 9, in <module>
          from pkg_resources.extern.pyparsing import stringStart, stringEnd, originalTextFor, ParseException
        File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
        File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
        File "<frozen importlib._bootstrap>", line 672, in _load_unlocked
        File "<frozen importlib._bootstrap>", line 632, in _load_backward_compatible
        File "/usr/local/lib/python3.10/site-packages/pkg_resources/extern/__init__.py", line 43, in load_module
          __import__(extant)
        File "/usr/local/lib/python3.10/site-packages/pkg_resources/_vendor/pyparsing.py", line 943, in <module>
          collections.MutableMapping.register(ParseResults)
      AttributeError: module 'collections' has no attribute 'MutableMapping'
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× Getting requirements to build wheel did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

From the backtrace we can see the frontend/installer is trying to load setuptools from /usr/local/lib/python3.10/site-packages/setuptools/__init__.py (outside of the environment), and that is the problem.

Please note here the current code for setuptools is not even loaded, so that is why I am failing to see how this problem can be related to setuptools implementation.

abravalheri · 2022-04-03T08:31:16Z

I think the best thing to do here is to ask pip maintainers if this behaviour is intended or if they have any clues why this might be happening.

skirpichev · 2022-04-03T09:49:49Z

Here I choose setuptools 47 because it is a version that does not try to mess with .pth files:

Just for record system-wide versions:

 ls -l /usr/local/lib/python3.10/site-packages/
total 32K
drwxr-s--- 3 sk staff 4.0K Nov  8 05:33 _distutils_hack
-rw-r----- 1 sk staff  152 Nov  8 05:33 distutils-precedence.pth
drwxr-s--- 5 sk staff 4.0K Nov  8 05:33 pip
drwxr-s--- 2 sk staff 4.0K Nov  8 05:34 pip-21.2.4.dist-info
drwxr-s--- 6 sk staff 4.0K Nov  8 05:33 pkg_resources
-rw-r--r-- 1 sk staff  119 Feb 19 07:15 README.txt
drwxr-s--- 7 sk staff 4.0K Nov  8 05:33 setuptools
drwxr-s--- 2 sk staff 4.0K Nov  8 05:33 setuptools-58.1.0.dist-info

I'll debug this further, thanks.

On another hand, I've used setup.cfg since 2018 which was fine with/without the --system-site-packages option. BTW, I've several CPython versions system-wide (coming from the distribution or locally built).

abravalheri · 2022-04-03T10:06:42Z

Hi @skirpichev, I opened an issue with pip asking if the have any thoughts on this problem pypa/pip#11004.
I further observed the same behaviour without using setuptools: pypa/pip#11004 (comment)

On another hand, I've used setup.cfg since 2018 which was fine with/without the --system-site-packages option.

It might be the case the version you had installed in the system's site-packages/dist-packages were always enough to provide the features you needed.

I don't know if you can do that in your machine, but is there any chance you can try to "uninstall" setuptools from your global system's site-packages/dist-packages just to see if the problem persists?

For example, if you are running:

python3.10 -m venv --system-site-packages ~/venv/xxx

Is it a possibility for you to python3.10 -m pip uninstall setuptools and/or temporarily rename the setuptools folder that you may find in /usr/local/lib/python3.10/site-packages and in /usr/lib/python3/dist-packages? The point here is to make sure python3.10 -c 'import setuptools' fails with a ModuleNotFoundError or an ImportError.

abravalheri · 2022-04-03T10:12:01Z

(Alternatively, if you have the rights you can also try to update the setuptools version on the system installation to see if the problem persists).

abravalheri · 2022-04-03T11:03:29Z

@skirpichev, there seems to be a problem with pip: pypa/pip#6264.

Please let me know if you can somehow confirming that once the system's site-packages/dist-packages does not contain setuptools (or it contains the correct version of setuptools) the installation works.

Otherwise I think the best thing to do right now is to close this ticket, because we cannot do much about it in setuptools.

skirpichev · 2022-04-04T03:03:02Z

Yes, you are right. Thanks for patience.

On another hand, I don't understand why this is working (setup.cfg-based example above with minor edit):

$ cat pyproject.toml 
[build-system]
requires = ['pip>=20.3', 'setuptools==60']
build-backend = 'setuptools.build_meta'
$ python3.10 -m venv --system-site-packages ~/venv/xxx
$ . ~/venv/xxx/bin/activate
$ pip install -U 'pip>=20.3' 'setuptools==60'  # ok
$ python3.10 -c 'import setuptools; print(setuptools.__version__)'
60.0.0
$ /usr/local/bin/python3.10 -c 'import setuptools; print(setuptools.__version__)'
58.1.0
$ pip install .  # ok!!!

Shouldn't this fail due to a bad setuptools version in the requires? Of course, probably this is just another side of the build frontend issue (i.e. pip) you reported.

abravalheri · 2022-04-04T06:57:16Z

If you setup.cfg based example does not require any advanced feature, building ir with setuptools 58.1.0 is probably fine and does not cause errors.

skirpichev · 2022-04-04T07:14:38Z

Well, the question was why the pip (or someone else?) does ignore the (strict!) version requirement for setuptools? Instead, it just silently uses a different version...

I would expect a failure in this situation (c.f. with the case you add an install_requires in the setup.cfg). And maybe it's a different problem wrt can or can't the pip use the setuptools from the system-wide environment. I.e. if it's ok that it can - I still would expect, that only with an acceptable version...

abravalheri · 2022-04-04T07:26:19Z

I am sure that is not intentional and they pretty much would prefer to have a failure or warning.

But all software is subject to bugs, and not always we realize they exist when we are coding. Other times it might also be super difficult to find the origin of the problem and fix it.

skirpichev · 2022-04-04T08:05:02Z

Ok, let me know if you feel that this deserve a separate issue for pip.

skirpichev added bug Needs Triage Issues that need to be evaluated for severity and status. labels Apr 2, 2022

abravalheri added invalid and removed bug Needs Triage Issues that need to be evaluated for severity and status. labels Apr 2, 2022

abravalheri closed this as completed Apr 2, 2022

abravalheri reopened this Apr 2, 2022

abravalheri mentioned this issue Apr 3, 2022

Backend loaded from system-wide location when virtual environment is created with --system-site-packages pypa/pip#11004

Closed

1 task

skirpichev closed this as completed Apr 4, 2022

b97pla mentioned this issue Mar 16, 2023

use pip and venv for deployment Molmed/snpseq-archive-db#7

Merged

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[BUG] unable to do a local install with pyproject.toml in a venv, created with --system-site-packages #3240

[BUG] unable to do a local install with pyproject.toml in a venv, created with --system-site-packages #3240

skirpichev commented Apr 2, 2022

abravalheri commented Apr 2, 2022 •

edited

Loading

abravalheri commented Apr 2, 2022

skirpichev commented Apr 2, 2022

abravalheri commented Apr 2, 2022

abravalheri commented Apr 2, 2022

abravalheri commented Apr 2, 2022 •

edited

Loading

abravalheri commented Apr 2, 2022

abravalheri commented Apr 2, 2022

skirpichev commented Apr 2, 2022

abravalheri commented Apr 2, 2022 •

edited

Loading

skirpichev commented Apr 3, 2022 •

edited

Loading

abravalheri commented Apr 3, 2022

abravalheri commented Apr 3, 2022

skirpichev commented Apr 3, 2022

abravalheri commented Apr 3, 2022

abravalheri commented Apr 3, 2022

abravalheri commented Apr 3, 2022 •

edited

Loading

skirpichev commented Apr 4, 2022

abravalheri commented Apr 4, 2022

skirpichev commented Apr 4, 2022

abravalheri commented Apr 4, 2022

skirpichev commented Apr 4, 2022

[BUG] unable to do a local install with pyproject.toml in a venv, created with --system-site-packages #3240

[BUG] unable to do a local install with pyproject.toml in a venv, created with --system-site-packages #3240

Comments

skirpichev commented Apr 2, 2022

setuptools version

Python version

OS

Additional environment information

Description

Expected behavior

How to Reproduce

Output

abravalheri commented Apr 2, 2022 • edited Loading

abravalheri commented Apr 2, 2022

skirpichev commented Apr 2, 2022

abravalheri commented Apr 2, 2022

abravalheri commented Apr 2, 2022

abravalheri commented Apr 2, 2022 • edited Loading

abravalheri commented Apr 2, 2022

abravalheri commented Apr 2, 2022

skirpichev commented Apr 2, 2022

abravalheri commented Apr 2, 2022 • edited Loading

skirpichev commented Apr 3, 2022 • edited Loading

abravalheri commented Apr 3, 2022

abravalheri commented Apr 3, 2022

skirpichev commented Apr 3, 2022

abravalheri commented Apr 3, 2022

abravalheri commented Apr 3, 2022

abravalheri commented Apr 3, 2022 • edited Loading

skirpichev commented Apr 4, 2022

abravalheri commented Apr 4, 2022

skirpichev commented Apr 4, 2022

abravalheri commented Apr 4, 2022

skirpichev commented Apr 4, 2022

abravalheri commented Apr 2, 2022 •

edited

Loading

abravalheri commented Apr 2, 2022 •

edited

Loading

abravalheri commented Apr 2, 2022 •

edited

Loading

skirpichev commented Apr 3, 2022 •

edited

Loading

abravalheri commented Apr 3, 2022 •

edited

Loading