1. Forum
  2. Usenet
  3. LINUX.DEBIAN.MAINT.PYTHON

  • How should upstream document/communicate none-Python =?UTF-8?Q?dependen

    From c.buhtz@posteo.jp@21:1/5 to All on Thu Feb 2 14:20:01 2023
    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)
  • From Joost van =?utf-8?Q?Baal-Ili=C4=87?@21:1/5 to All on Thu Feb 2 15:20:01 2023
    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)
  • From Jeremy Stanley@21:1/5 to All on Thu Feb 2 15:20:01 2023
    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)
  • From Jeremy Stanley@21:1/5 to c.buhtz@posteo.jp on Thu Feb 2 15:40:01 2023
    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