Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #17395 > unrolled thread

Is pip(x) used internally while Debian packaging?

Back to article view | Back to linux.debian.maint.python

Contents

  Is pip(x) used internally while Debian packaging? <c.buhtz@posteo.jp> - 2026-02-14 13:10 +0100
    Re: Is pip(x) used internally while Debian packaging? Mechtilde Stehmann <mechtilde@debian.org> - 2026-02-14 14:40 +0100
      Re: Is pip(x) used internally while Debian packaging? c.buhtz@posteo.jp - 2026-02-14 17:10 +0100
    Re: Is pip(x) used internally while Debian packaging? Stefano Rivera <stefanor@debian.org> - 2026-02-14 15:00 +0100

#17395 — Is pip(x) used internally while Debian packaging?

Hello Folks,
from my perspective as upstream maintainer I try to learn some
internals.

Imagine a modern Python application following PEP 517 & 621
(pyproject.toml and src-layout). Translations are handled via GNU
gettext. Hatch(ling) is used as build system using "initialize" build
hook to compile po into mo files and add them into the wheel.
The application does access them via "importlib.resources".

How does this interfere with Debian packaging?
I don't want to create extra work for people like you.

In a Debian package the mo files do not belong into the wheel but into
/usr/share/locale.

Is the Python build system relevant while Debian packing? Is pip used
internally while you create the deb file? Or do you use your own way
and the build system used by upstream does not matter?

I know you have a lot of tools to add extra ways and exceptions to
overwrite upstream behavior. But I want to prevent that, spare your
time and make it right from the very first beginning.

Regards,
Christian Buhtz

[toc] | [next] | [standalone]

#17397

[Multipart message — attachments visible in raw view] — view raw

Hello Christian,

Am 14.02.26 um 12:59 schrieb c.buhtz@posteo.jp:
> Hello Folks,
> from my perspective as upstream maintainer I try to learn some
> internals.

Do you know and understand

https://www.debian.org/doc/packaging-manuals/python-policy/

> 
> Imagine a modern Python application following PEP 517 & 621
> (pyproject.toml and src-layout). Translations are handled via GNU
> gettext. Hatch(ling) is used as build system using "initialize" build
> hook to compile po into mo files and add them into the wheel.
> The application does access them via "importlib.resources".
> 
> How does this interfere with Debian packaging?
> I don't want to create extra work for people like you.
> 
> In a Debian package the mo files do not belong into the wheel but into
> /usr/share/locale.
> 
> Is the Python build system relevant while Debian packing? Is pip used
> internally while you create the deb file? Or do you use your own way
> and the build system used by upstream does not matter?

The main rule in Debian is:

There is no internet connection during build time. All  needed 
dependencies *must* be available in de Debian archive.

> I know you have a lot of tools to add extra ways and exceptions to
> overwrite upstream behavior. But I want to prevent that, spare your
> time and make it right from the very first beginning.

Is there already a similar package in  the Debian archive? This can help 
to understand the process.

Do you have the project online so we can review it like a peer review?

> 
> Regards,
> Christian Buhtz
> 


Regards
-- 
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F

[toc] | [prev] | [next] | [standalone]

#17400

Thank you for the answers. I thought it wouldn't be that simple. ;)

Am 14.02.2026 14:39 schrieb Mechtilde Stehmann:
> Do you have the project online so we can review it like a peer review?

Not yet. I'll come back if I can provide an example.

It will be "Feedybus" <https://codeberg.org/buhtz/Feedybus>
And what I'll learn from there will go into "Back In Time" after I 
migrated its build system from make to modern Python standards.

Regards,
Christian

[toc] | [prev] | [next] | [standalone]

#17399

Hi c.buhtz (2026.02.14_11:59:50_+0000)
>Imagine a modern Python application following PEP 517 & 621
>(pyproject.toml and src-layout). Translations are handled via GNU
>gettext. Hatch(ling) is used as build system using "initialize" build
>hook to compile po into mo files and add them into the wheel.
>The application does access them via "importlib.resources".
>
>How does this interfere with Debian packaging?
>I don't want to create extra work for people like you.

If it's package data inside the package, it should all end up in the 
right place for importlib.resources to find.

Python build tools don't provide a mechanism to install things like 
manpages into the right place (because python packaging isn't aimed at a 
complete system, but a Python environment). So the packager has to move 
things around, themselves.

>In a Debian package the mo files do not belong into the wheel but into
>/usr/share/locale.

I don't know the correct pattern for this offhand, but I'd imagine that 
you can try both a path located via improtlib.resources, and the default 
localedir, when configuring your translations.

>Is the Python build system relevant while Debian packing? Is pip used
>internally while you create the deb file? Or do you use your own way
>and the build system used by upstream does not matter?

Pip is not used. We use "build", another PEP 517 implementation, to 
build a wheel, that we then install the contents of.

Stefano

-- 
Stefano Rivera
   http://tumbleweed.org.za/
   +1 415 683 3272

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web