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

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

How should upstream document/communicate none-Python dependencies?

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

Contents

  How should upstream document/communicate none-Python  dependencies? c.buhtz@posteo.jp - 2023-02-02 14:20 +0100
    Re: How should upstream document/communicate none-Python  dependencies? c.buhtz@posteo.jp - 2023-02-02 15:20 +0100
      Re: How should upstream document/communicate none-Python  dependencies? Jeremy Stanley <fungi@yuggoth.org> - 2023-02-02 15:40 +0100
    Re: How should upstream document/communicate none-Python  dependencies? Jeremy Stanley <fungi@yuggoth.org> - 2023-02-02 15:20 +0100
    Re: How should upstream document/communicate none-Python  dependencies? Joost van Baal-Ilić <joostvb+debian-python@uvt.nl> - 2023-02-02 15:20 +0100

#14875 — How should upstream document/communicate none-Python dependencies?

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

[toc] | [next] | [standalone]

#14876

Thanks for your reply.

Am 02.02.2023 14:46 schrieb Jeremy Stanley:
> with https://pypi.org/project/bindep which is effectively a manifest
> of distribution package names and a grammar for indicating

Awesome.

The upstream maintainers have to create a binddep.txt file.
And the distro maintainers do need to use binddep do parse that file and 
"translate" it into the package names of their distro.
Am I right so far?

What does other debian python package maintainers think about such a 
tool? Would this ease your (burden) of work preparing a new package 
(release)?

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

#14879

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

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

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

#14877

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

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

#14878

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

[toc] | [prev] | [standalone]

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

csiph-web