Hello,pyproject.toml.
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
</pre></blockquote></div></body></html> ------0IASHK2NLIL0SPI1K4RMCGF3VLHOD2--
AFAIK Debian helper for Python handles this
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?
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.
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. ;)
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.
Hello,I feel like this question is not really specific to pyproject.toml etc.:
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?
The only package I maintain that I can think of at the moment withentrypoints 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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 349 |
Nodes: | 16 (2 / 14) |
Uptime: | 117:44:05 |
Calls: | 7,612 |
Files: | 12,786 |
Messages: | 5,683,923 |