Python policy about /usr/lib/

2022-11-04 Thread Julien Palard
The Python Policy document [1] states:

> For all supported Debian releases, sys.path does not include a 
> /usr/lib/ 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/', ...

$ /usr/bin/python3.10 -S -c 'print(__import__("sys").path)'
['', '/usr/lib/', ...

Any idea of what's wrong here?

[Julien Palard](

Request to join the Debian Python Team

2022-07-06 Thread Julien Palard

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.


Julien Palard

Re: Need a Python 3.8 virtual environment

2021-03-03 Thread Julien Palard
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
 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

[Julien Palard](

Re: upstream python concerns, python3-full package for bullseye

2021-02-12 Thread Julien Palard

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.)


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](