Your message dated Mon, 30 Dec 2024 21:34:37 -0500
with message-id <[email protected]>
and subject line Re: Bug#1091740: python3-venv: priority is not given to
virtual packages over system packages when they both have the same name.
has caused the Debian Bug report #1091740,
regarding python3-venv: priority is not given to virtual packages over system
packages when they both have the same name.
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1091740: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091740
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: python3-venv
Version: 3.11.2-1+b1
Severity: important
Dear Maintainer,
* What led up to the situation?
1. I installed python3-keystone (openstack identity service)
2. I installed a python program in a virtual environment from
(https://github.com/korcankaraokcu/PINCE) this application installs
keystone-engine (an on-the-fly assembler) via pip into the virtual
environment using the venv module.
* What was the outcome of this action?
When launching pince (in the virtual environment) the keystone package
is loaded from the system path rather than the virtualized path:
[system]: /usr/lib/python3/dist-packages/keystone/__init__.py
[virtual]: <VIRTUALPATH>/lib/python3.11/site-
packages/keystone/__init__.py
* What outcome did you expect instead?
I expected the virtual environment to load the package (keystone) from
the virtual environment and not from the system path.
In other words, priority should be given to loading packages from the
virtual environment (site-packages directory) and never from the system
(dist-packages directory) unless the package does not exist in the
virtual environment.
-- System Information:
Debian Release: 12.8
APT prefers stable-updates
APT policy: (1090, 'stable-updates'), (1090, 'stable-security'), (1090,
'stable-debug'), (1090, 'proposed-updates-debug'), (1090, 'proposed-updates'),
(1090, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-28-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-venv depends on:
ii python3 3.11.2-1+b1
ii python3-distutils 3.11.2-3
ii python3.11-venv 3.11.2-6+deb12u5
python3-venv recommends no packages.
python3-venv suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
As it turns out the issue was with the pince python application, and not
the python3-venv module, and I am closing
this bug since python3-venv is working correctly per earlier testing.
---
Since pince needs gdb to debug process memory, the developers had
created a file (gdbinit_venv) to
handle settings gdb's python search path.
The trouble is they were calling sys.path.extend(paths) rather than
replacing the path; this resulted
in the virtual path being appended to the end of gdb's default list
(which already contained the
python system path /usr/lib/...).
A fix is in the process of being applied to gdbinit_venv to correct the
issue.
--- End Message ---
