Ben Finney <ben+deb...@benfinney.id.au> writes:
> The application has “console scripts” defined in the Distutils
> `entry_points` mapping:
>
> $ cat ./setup.py
> […]
> entry_points={
> 'console_scripts': [
> "foo=FooApp.foo:main",
> ],
> },
> […]
>
> which installs command-line programs at `/usr/bin/foo`, for example.
> Good.
In an earlier message, a workaround was offered specifically for the
case of user commands (“scripts”): don't use entry points, instead make
symlinks from ‘/usr/share/FooApp/lorem/dolor.py’ to ‘/usr/bin/foo’.
That isn't sufficient, for several reasons:
* A ‘console_script’ entry point specifies a specific function within
the module. Running the module file as ‘__main__’ isn't always a
replacement for that.
* Distutils clobbers the execute bit on module files when installing
them, so telling Debhelper to just make a symlink still doesn't result
in an executable command.
* This doesn't address the problem that ‘pkg_resources’ still can't find
the application's distribution metadata.
Other queries to `pkg_resources` for this application's distribution,
for example to get the distribution version or homepage URL, will also
fail.
Would it be correct design for Pybuild to place Python libraries in one
location and the Distutils metadata in a different location; the former
private, the latter available at least to the application itself?
I don't quite know how that would work, but it sounds like what I'd
expect if we're going to have sensible “application private modules in
‘/usr/share/FooApp/’ where they aren't public” behaviour.
--
\ “As scarce as truth is, the supply has always been in excess of |
`\ the demand.” —Josh Billings |
_o__) |
Ben Finney
