Python policy about /usr/lib/pythonXY.zip
The Python Policy document [1] states:
> For all supported Debian releases, sys.path does not include a
> /usr/lib/pythonXY.zip entry.
I may not understand the sentence, or something, because it looks wrong to me
as pythonXY looks to be in sys.path, at least on my Debian bookworm:
$ /usr/bin/python3.10 -c 'print(__import__("sys").path)'
['', '/usr/lib/python310.zip', ...
$ /usr/bin/python3.10 -S -c 'print(__import__("sys").path)'
['', '/usr/lib/python310.zip', ...
Any idea of what's wrong here?
[1]: https://www.debian.org/doc/packaging-manuals/python-policy/
--
[Julien Palard](https://mdk.fr)
Request to join the Debian Python Team
Hello, I would like to join the Debian Python Team to package some of my projects, mainly sphinx-lint [1], but maybe also pospell [2], pogrep [3], and friends created while translating the Python documentation in french. My salsa handle is mdk. I have read the policy [4] and accept it. [1]: https://github.com/sphinx-contrib/sphinx-lint [2]: https://github.com/AFPy/pospell/ [3]: https://github.com/AFPy/pogrep/ [4]: https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#joining-the-team Bests, -- Julien Palard https://mdk.fr
Re: Need a Python 3.8 virtual environment
Le 2021-03-03 à 04:17, Steven Robbins a écrit : > I'm trying to use a (non-Debian) python system built on python 3.8. Debian's > default is currently 3.9 so I am advised to use a virtual environment. As other told, the right way is probably to compile it yourself (or use pyenv, but I don't like pyenv "shims", I prefer to keep it simple). I'm using a bash function [1] to easily recompile needed Pythons (I test some projects with Python 3.5 to 3.9), but it's not that hard without my bash function: apt install make build-essential libbz2-dev liblzma-dev libssl-dev llvm libreadline-dev libncurses5-dev libffi-dev zlib1g-dev tk-dev libsqlite3-dev xz-utils wget the version you want from https://www.python.org/ftp/python tar -xzf it ./configure --prefix=$HOME/.local/ make -j $(nproc) make altinstall You'll get a `python3.8` binary in ~/.local/bin, you can create venvs with it as: python3.8 -m venv the_venv_path [1]: https://github.com/JulienPalard/dotfiles/blob/0b5feb79b1ba648b7212162b68da5a182e0341c1/.bashrc#L196 -- [Julien Palard](https://mdk.fr)
Re: upstream python concerns, python3-full package for bullseye
Hi,
As far as I understand, the divergence between "Python upstream" and
Debian is:
- It looks like Debian target users consuming software, users just
install a package and it works, no venv needed obviously, it always just
work, it's fantastic. Users may not even care if the program is written
in Python or not at this point.
- Upstream Python is obviously composed by people writing in Python and
know many people who write some Python too: all in need of venv to work.
> Also, it's a disservice to push our users into the direction of using
> venv which is very ugly way to use Python in a Debian system
I do agree, we could even replace Python with software in this sentence.
And I don't think we're pushing our users to always install things in
venvs. Providing venv is not a big signal for Debian users to ask them
to use it to install packages (if a signal at all).
With my "I do write things in Python that may run on non-Debian systems"
hat, and "I teach Python" (most of them not using Debian) hat, a venv is
helping me in many many ways, it's literally part of my daily routine:
- It allows me to pin a set of dependencies and sub-dependencies to an
exact version (I do use pip-compile, from pip-tools), per project, that
I can use in automatic tests (ensuring if tests passes today, they'll
pass tomorrow), I can share this set with coworkers and future me ("if
it works for me, it works for you"), note my coworkers may not use
Debian at all.
- It allows me to easily replace a dependency with a modified one to
test it, or make anyone else test it (for example [1]).
- It allows me to work on my Debian testing laptop on code aimed to work
on Debian stable, or a completly different OS.
- It allows me to work on various projects with a different set of
incompatible dependencies.
So while I do agree that a *normal user* does not need a venv as I
myself appreciate, as a user, how fantastic it is to be able to install
a software using Debian packages, I still think venv is a very usefull
tool that I'm very happy to have in the Python stdlib and use daily.
(My current use of Python on Debian is: compile it myself, I need
multiple versions of Python for test purposes anyway.)
[1]: https://github.com/PyCQA/pylint/pull/3890#issuecomment-727591305
P.S.: If you still feel I'm completly wrong to use venv and pip in my
workflow, I'll be very happy to learn better ways.
--
[Julien Palard](https://mdk.fr)
