Hello,

I'm part of upstream maintainer team of "backintime" (BIT).

A modern Python project (which BIT is currently not) would specify
dependencies and other build related information's into a pyproject.toml
file.
But some Python applications (e.g. BIT) do have non-Python dependencies
to specific Debian packages e.g. "rsync".

As upstream I do document that into README or somewhere else in a human readable file.

But is there a machine readable way to specify things like this? Maybe
there is a special pyproject.toml section I don't know about yet? Or
something like MANIFEST or requirements files I've heard of but never
used.

How would you wish this as distro maintainers?

Side question: Do you, as distro maintainers, have automatic tools to
translate dependencies from pyproject.toml (e.g. "pyfakefs") into the
related Debian package (e.g. "python3-pyfakefs")?

Kind
Christian Buhtz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Op Thu, Feb 02, 2023 at 01:10:03PM +0000 schreef c.buhtz@posteo.jp:

I'm part of upstream maintainer team of "backintime" (BIT).

A modern Python project (which BIT is currently not) would specify dependencies and other build related information's into a pyproject.toml file.
But some Python applications (e.g. BIT) do have non-Python dependencies to specific Debian packages e.g. "rsync".

As upstream I do document that into README or somewhere else in a human readable file.

But is there a machine readable way to specify things like this? Maybe there is a special pyproject.toml section I don't know about yet? Or something
like MANIFEST or requirements files I've heard of but never used.

How would you wish this as distro maintainers?

Side question: Do you, as distro maintainers, have automatic tools to translate dependencies from pyproject.toml (e.g. "pyfakefs") into the
related Debian package (e.g. "python3-pyfakefs")?

Afaik there is no such thing. One hard problem to tackle first would
be to map the name of e.g. an RPM package to the equivalent one in
the Debian/dpkg world. These are sometimes, but _not_ always, the same...

Bye,

Joost

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In the OpenStack ecosystem we mostly solved this around 8 years ago
with https://pypi.org/project/bindep which is effectively a manifest
of distribution package names and a grammar for indicating
differences in package naming or requirements between different
distributions and versions thereof. It's used quite heavily by
hundreds of projects in our ecosystem, and has been picked up by a
lot of projects outside OpenStack as well. Where it mostly shines is
when you want to provide some means of confirming you have the
correct packages in your development system to be able to
install/run a project and its tests, but we also rely on it heavily
in automated CI jobs to determine what non-Python packages should be
installed for tests to execute correctly.
--
Jeremy Stanley

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-02-02 14:16:11 +0000 (+0000), c.buhtz@posteo.jp wrote:
[...]

The upstream maintainers have to create a binddep.txt file.

Yes, it would look something like this:

https://opendev.org/openstack/nova/src/branch/master/bindep.txt

And then projects relying on it document using the bindep tool like
this:

https://docs.openstack.org/nova/latest/contributor/development-environment.html#linux-systems

Another goal of that tool is for it to use a file format which is
reasonably human-readable, so that someone can work out dependencies
fairly quickly from it even if they can't or don't want to install
another tool to parse it.

And the distro maintainers do need to use binddep do parse that file and "translate" it into the package names of their distro.

[...]

Yes, I don't know whether the OpenStack packaging team in Debian
relies on it at all, but the intent is for it to be usable by
prospective package maintainers for projects, at least as a means of double-checking against their declared dependencies. Its grammar
allows projects to distinguish between arbitrary kinds of
dependencies through the use of free-form "profile" names and many
projects have settled on some common ones (particularly "test") to
separate hard dependencies from optional or testing-related
dependencies, but these concepts vary widely enough between
different distros that I wouldn't expect a package maintainer to
take the filtered bindep results directly without some manual
vetting.
--
Jeremy Stanley

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmPbyf9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCl48A/9GgznEK41tSzHivmd4M/UyQM8SnLLAz2Zfz8Bo+BkYLN8kNjj0ZnXku9s ei+2xXEYguvcms6gpKcdUe3BFHkzXa1IXqfLehQMI7p1kM5uTylMbQwivjDsyCYF i9tyPuKJmNHRHLv1ACi/rpJUA4VtK4HPNP2kfnp03ZvPERORg79nEXGy81DroxFa 1LB6Wtgjor3v43S0IGTK0xtL20A/tb1mHlopCLfkBteuZZDt6jiaiizG+GlCDT6P ym2oOLPYwqAHL2wvk0NV6xrlDSa3bbgD8CX0ywIx64L4izrdVZrm/+jfDZeO7dXE MoBLfgoTccLUtk1Kh4Eq3WIV9ujhYfu6tcylyhRkVk+CbvMbjrKmayvsZtTWXPOL eA/AS0tzpxFEw6DQm7tQaL+OHfb7L9U2O398PkJgrCVqYbmnY0N7FejZDjRqJQp/ YmsazKbnbQOkd/tJo/xNzKvcV3o2luoYNMVBW5hYEUWykUjeACf5uK+M24l5wifG G6AE5qT3uW5tLf0vmnPU7JXP+3tkMrrVvlr9vUIxledTb8YcHDDI8EAqjKN98cwv 1AtArJAqMuoA83P5XPDS38XBk1xc2klHpWtRiAY4H45tuHoYEq/SamK6oeaGyuXI hAYtoMDi6BKbcwoeYk3ocwKlb+mhu+N8MNOdUCU9pq/C+bsSCDQ=
=lHZ4
-----END PGP SIGNATURE-----

--- SoupGate-Win32