Hugo Lefeuvre <h...@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
