• How do you create entry-points for Python =?UTF-8?Q?applications?= =?UT

    From c.buhtz@posteo.jp@21:1/5 to All on Sun Dec 18 20:20:01 2022
    Hello,
    a python application isn't a binary but a script. So to invoke such an application there need to be a shell script somewhere in PATH that
    invoke that script via python3 interpreter. Imagine an application with
    a GUI (qt, tikinter, gtk, ...).

    On the upstream site modern python projects using pyproject.toml (only),
    some use setup.cfg.
    There you can define "entry points" and the "pip" installer does
    generate a shell script based on that information and place it in PATH.
    That is a nice mechanism when installing via pip.

    On your site as distro maintainers. How do you take care of then when
    creating deb files?
    When a project do follow modern python packaging standards using pyproject.toml/setup.cfg and doesn't offer any other explict start shell script. Do you use that pip mechanic for the deb package?
    Or how do you create your shell scripts?

    I don't have an real world example of a python application for that.

    I only have an example of a project (backintime) that don't use pyproject.toml/setup.cfg and offer its own shell script. I'm part of the
    new maintainer team and we will evolve the project to current python
    packaging standards; which means using pyproject.toml.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?RGFuaWFsIEJlaHphZGkg2K/Yp@21:1/5 to All on Sun Dec 18 23:10:02 2022
    ------0IASHK2NLIL0SPI1K4RMCGF3VLHOD2
    Content-Type: text/plain;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    AFAIK Debian helper for Python handles this

    در 18 دسامبر 2022 19:18:44 (UTC)، c.buhtz@posteo.jp نوشت:
    Hello,
    a python application isn't a binary but a script. So to invoke such an application there need to be a shell script somewhere in PATH that invoke that script via python3 interpreter. Imagine an application with a GUI (qt, tikinter, gtk, ...).

    On the upstream site modern python projects using pyproject.toml (only), some use setup.cfg.
    There you can define "entry points" and the "pip" installer does generate a shell script based on that information and place it in PATH.
    That is a nice mechanism when installing via pip.

    On your site as distro maintainers. How do you take care of then when creating deb files?
    When a project do follow modern python packaging standards using pyproject.toml/setup.cfg and doesn't offer any other explict start shell script. Do you use that pip mechanic for the deb package?
    Or how do you create your shell scripts?

    I don't have an real world example of a python application for that.

    I only have an example of a project (backintime) that don't use pyproject.toml/setup.cfg and offer its own shell script. I'm part of the new maintainer team and we will evolve the project to current python packaging standards; which means using
    pyproject.toml.


    ------0IASHK2NLIL0SPI1K4RMCGF3VLHOD2
    Content-Type: text/html;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    <html><head></head><body>AFAIK Debian helper for Python handles this<br><br><div class="gmail_quote">در 18 دسامبر 2022 19:18:44 (UTC)، c.buhtz@posteo.jp نوشت:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px
    solid rgb(204, 204, 204); padding-left: 1ex;">
    <pre dir="auto" class="k9mail">Hello,<br>a python application isn't a binary but a script. So to invoke such an application there need to be a shell script somewhere in PATH that invoke that script via python3 interpreter. Imagine an application with a
    GUI (qt, tikinter, gtk, ...).<br><br>On the upstream site modern python projects using pyproject.toml (only), some use setup.cfg.<br>There you can define "entry points" and the "pip" installer does generate a shell script based on that information and
    place it in PATH.<br>That is a nice mechanism when installing via pip.<br><br>On your site as distro maintainers. How do you take care of then when creating deb files?<br>When a project do follow modern python packaging standards using pyproject.toml/
    setup.cfg and doesn't offer any other explict start shell script. Do you use that pip mechanic for the deb package?<br>Or how do you create your shell scripts?<br><br>I don't have an real world example of a python application for that.<br><br>I only have
    an example of a project (backintime) that don't use pyproject.toml/setup.cfg and offer its own shell script. I'm part of the new maintainer team and we will evolve the project to current python packaging standards; which means using pyproject.toml.<br><
    </pre></blockquote></div></body></html> ------0IASHK2NLIL0SPI1K4RMCGF3VLHOD2--

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From c.buhtz@posteo.jp@21:1/5 to All on Mon Dec 19 06:20:01 2022
    Am 18.12.2022 23:03 schrieb Danial Behzadi دانیال بهزادی:
    AFAIK Debian helper for Python handles this

    ;) Yes, but how?

    Does it ignore the pip-default-entry-point-scripts? Does it create its
    own script?
    Do you have to explicit write a script?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Kitterman@21:1/5 to c.buhtz@posteo.jp on Mon Dec 19 06:30:01 2022
    On December 19, 2022 5:13:27 AM UTC, c.buhtz@posteo.jp wrote:
    Am 18.12.2022 23:03 schrieb Danial Behzadi دانیال بهزادی:
    AFAIK Debian helper for Python handles this

    ;) Yes, but how?

    Does it ignore the pip-default-entry-point-scripts? Does it create its own script?
    Do you have to explicit write a script?

    You don't. Pybuild using the pyproject plugin will build a wheel and then install the necessary files in the package using the installer module. The entry point scripts are in the wheel, just like an upstream built wheel.

    Your best bet is to find a package in the archive that's similar and see how it was done.

    Scott K

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From c.buhtz@posteo.jp@21:1/5 to All on Mon Dec 19 07:30:01 2022
    Dear Scott,

    thanks for the reply.

    Am 19.12.2022 06:25 schrieb Scott Kitterman:
    Pybuild using the pyproject plugin will build a wheel and
    then install the necessary files in the package using the installer
    module. The entry point scripts are in the wheel, just like an
    upstream built wheel.

    Do I get that correct?
    The entry scripts (their content and their location) is the same
    installing a package via pip and apt?

    In that case I'm right trying to make the "pip install" process as
    correct as possible to save resources for the distro maintainers.

    Your best bet is to find a package in the archive that's similar and
    see how it was done.

    That is why I'm asking here. ;)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Kitterman@21:1/5 to c.buhtz@posteo.jp on Mon Dec 19 08:00:01 2022
    On December 19, 2022 6:27:55 AM UTC, c.buhtz@posteo.jp wrote:
    Dear Scott,

    thanks for the reply.

    Am 19.12.2022 06:25 schrieb Scott Kitterman:
    Pybuild using the pyproject plugin will build a wheel and
    then install the necessary files in the package using the installer
    module. The entry point scripts are in the wheel, just like an
    upstream built wheel.

    Do I get that correct?
    The entry scripts (their content and their location) is the same installing a package via pip and apt?

    In that case I'm right trying to make the "pip install" process as correct as possible to save resources for the distro maintainers.

    There are exceptions, but generally that is correct.

    Your best bet is to find a package in the archive that's similar and
    see how it was done.

    That is why I'm asking here. ;)

    Hopefully someone will chime in with a good example. The only package I maintain that I can think of at the moment with entrypoints and project.toml is too complicated to be a good example.

    Scott K

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?RGFuaWFsIEJlaHphZGkg2K/Yp@21:1/5 to All on Mon Dec 19 14:10:01 2022
    ------707OW9AETL3TCD79CYJ2NLQZL99PKA
    Content-Type: text/plain;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    The only package I maintain that I can think of at the moment with entrypoints and project.toml is too complicated to be a good example.

    That shouldn't be so much different from setup.py projects and there are plenty of them in archive.
    ------707OW9AETL3TCD79CYJ2NLQZL99PKA
    Content-Type: text/html;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    <!DOCTYPE html><html><body>&gt; The only package I maintain that I can think of at the moment with entrypoints and project.toml is too complicated to be a good example.<br><br>That shouldn't be so much different from setup.py projects and there are
    plenty of them in archive.</body></html>
    ------707OW9AETL3TCD79CYJ2NLQZL99PKA--

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rahmatullin@21:1/5 to c.buhtz@posteo.jp on Mon Dec 19 14:40:01 2022
    On Sun, Dec 18, 2022 at 07:18:44PM +0000, c.buhtz@posteo.jp wrote:
    Hello,
    a python application isn't a binary but a script. So to invoke such an application there need to be a shell script somewhere in PATH that invoke that script via python3 interpreter. Imagine an application with a GUI (qt, tikinter, gtk, ...).

    On the upstream site modern python projects using pyproject.toml (only),
    some use setup.cfg.
    There you can define "entry points" and the "pip" installer does generate a shell script based on that information and place it in PATH.
    That is a nice mechanism when installing via pip.

    On your site as distro maintainers. How do you take care of then when creating deb files?
    I feel like this question is not really specific to pyproject.toml etc.:
    entry points are an old concept and we have a lot of packages shipping setuptools entry points (grep your /usr/bin for "load_entry_point").
    For these packages the executable is indeed created automatically by the packaging tools, and I would expect the same to happen for any other
    supported setuptools replacement.

    --
    WBR, wRAR

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

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmOgYhMtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh 2mQP/jzixv3IfFTsPOoYXQimfF7iY2ilxPmbs2je5PVoRoGMQOXkUIScD2u5Tnks NzZZARhSQIPpYQqPfiBBl4hJ/oiz8s0G12dBV9c5vTDkK8/aSAJG7gHA38J/JU8U XlT4Cl9e4Ls04PAKIw0+eWyhIQfUO6irB8TZFg52JNfIYYGIELWyyB7/LARUa1sh Wj7IoAih22uzjloM7m+96WkfjRc/xhf3KAyp7ELW3kTzVUK/K9/BgCTMSipKICDO V7vkuQuvQ2SwUGvQLQyrqac2IkQD/Ux0g/P9RE5Ma1S6YV67trOrceNJcQKhv6cG MUWbeVbbT/mZ4QfH1Th/CJkgdeM6tYDZv2McZlashMKgZbgU7Ywkwm2KDJq2uYQe fz7MYWidKe0lF0PxlxyFxE/ZbC1ruVAIbPi8JnYjiCTdXbF4PYQzixiShEUxYNmK nTE/z2FtTqfsoisdRWDZz3hPpqvNg/fZ/YaaSd3TbSBbUz47mA+GqLG6Ie3NgNsx IDF4daWFVc4k5E4JCbLVdYYqU57X5xwHjmZACOMpux6e5MDHunXaQ0pHfeBWoRVY T+BFKlY04iqWKTzXrHjiu8Wwge/xqWySjW9gkkofh4/wNNAj2MdbZvlmKnElm9zc EO7j15JI4UQS9XCNXo/DDFQKbvcxXKLEGaBUw7fSHtG9BrXG
    =o3G8
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stuart Prescott@21:1/5 to All on Tue Dec 20 01:10:01 2022
    On 20/12/2022 00:09, Danial Behzadi دانیال بهزادی wrote:
    The only package I maintain that I can think of at the moment with
    entrypoints and project.toml is too complicated to be a good example.

    That shouldn't be so much different from setup.py projects and there are plenty of them in archive.

    In general, the Debian tooling installs the package and so the upstream
    build system should generate the entry points scripts no matter which
    approach is used.

    There are some differences to be aware of:

    If the pybuild 'distutils' plugin is used (i.e. with a setup.py
    project), then the entry points will be created at the "install" step
    and should land in debian/*/usr/bin; you may need to move them into the
    right binary package.

    If the pybuild 'pyproject' plugin is used (i.e. with a pyproject.toml
    project), then the entry points will be created in the "build" step.
    They will land in the pybuild {home_dir}/scripts directory and be
    available to the "test" target in PATH for any cli tests that are in the
    test suite. They will get copied into debian/*/usr/bin during the
    "install" step and you may need to move them into the right binary package.

    The main things that the packager needs to be aware of are:

    * the packaging needs to move the entry points scripts into the correct
    binary package; that might be a debian/package.install file or it might
    be a mv in debian/rules.

    * make sure there's a tight enough dependency between the package that
    contains the entry points scripts and the package that contains the
    modules; the entry points scripts include exact versioning on the
    upstream version of the module and if the binary packages don't have dependencies that enforce that requirement, the entry points script can
    fail at run time for the user. («python3-foo (= ${binary:Version})»
    should be ok for packages that are only arch:all).

    cheers
    Stuart

    --
    Stuart Prescott http://www.nanonanonano.net/ stuart@nanonanonano.net
    Debian Developer http://www.debian.org/ stuart@debian.org
    GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

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