cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake | IRC logs: and | the pypy angle is to shrug and copy the implementation of CPython as closely as possible, and staying out of design decisions
greedom has quit [Remote host closed the connection]
jcea has quit [Ping timeout: 248 seconds]
derpydoo has joined #pypy
otisolsen70 has joined #pypy
derpydoo has quit [Quit: derpydoo]
derpydoo has joined #pypy
lritter has joined #pypy
Techcable has quit [Ping timeout: 276 seconds]
lritter has quit [Ping timeout: 248 seconds]
otisolsen70 has quit [Quit: Leaving]
derpydoo has quit [Quit: derpydoo]
jcea has joined #pypy
<mgorny> i've just hit a curious problem, and i'm going to investigate further
<mgorny> i have virtualenv-20.21.0 installed on system, and 20.22.0 installed for testing in a venv with --system-site-packages
<mgorny> some of the tests use importlib.metadata to grab entry points from virtualenv
<mgorny> for some reason, on pypy3 it ends up using entry points from the old system virtualenv (i don't know if "instead" or "in addition to" the ones in venv)
<mgorny> but on cpython it doesn't seem to happen
<mgorny> (this exhibits in test failures because it tries to load stuff that was removed in 20.22.0)
lritter has joined #pypy
<mgorny> oh, i was wrong
<mgorny> i've been comparing pypy3.9 with cpython3.10
<mgorny> so apparently it's specific to importlib.metadata from python3.9
<tumbleweed> :)
<mgorny> ...and upstream doesn't care to fix it (i.e. to use external importlib_metadata instead of buggy importlib.metadata on <3.10), so i guess another reason to have pypy3.10 asap
joshszep_work has joined #pypy
joshszep_work has quit [Client Quit]
<nimaje> hm, with --system-site-packages I would expect it to use whatever is installed system wide in addition to stuff installed in the venv (be it moduls, entry points or whatever)
lritter has quit [Ping timeout: 240 seconds]
Techcable has joined #pypy
ammar2 has joined #pypy