Re: Python package providing both modules and an app
Hugo Lefeuvre <hle@debian.org> writes:
> I'm currently packaging python-slugify[0], a Python application for
> slugifying unicode strings.
Thank you for considering the issues and asking for advice.
> Like here[1] upstream decided to write everything as a python module
> with an entry script placed in /usr/bin that calls main(). So we can
> consider python-slugify as both an application and a library.
This seems to be more common now that command-line invocation is
becoming even more discouraged. When the upstream documentation
recommends ‘python3 -m foo.bar’ as the primary means of invoking the
command line functionality, that really blurs the line between
command-line application versus library.
There is a compounding tendency to disparage ‘python3 ./foo/bar.py’,
which is subject to weird hacks and incomplete workarounds like
<URL:https://www.python.org/dev/peps/pep-0366/>. I wish this trend could
be effectively reversed, because IMO this is a serious impediment to
considering Python a good choice for command-line scripting. But this is
all a digression, my apologies.
> The package is originally requested as a Python module[2] and it seems
> clear to me that the whole thing is only useful as a library
I don't understand this statement. If it is *only* useful as a library,
why install the command-line entry point?
> Everything is working well. However, I'm not really satisfied by the way I
> solved the problem in debian/rules[4]. Does anybody know a better way
> of doing that ?
Why not install the command by using the configuration files for
‘dh_install(1)’; that is, specify in ‘debian/slugify.install’ the files
to install.
--
\ “If you can do no good, at least do no harm.” —_Slapstick_, |
`\ Kurt Vonnegut |
_o__) |
Ben Finney
Reply to: