Re: Application libraries private, Distutils metadata available for console scripts and introspection

[Ben Finney, 2015-11-26] > * Patch upstream's ‘setup.py’ to rename the command file to something > like ‘execute-lorem’, so that it can be installed alongside the > ‘lorem’ package directory. instead of patching I usually let it install into /usr/bin and mv it to /usr/share/foo/ under a

Re: Application libraries private, Distutils metadata available for console scripts and introspection

Piotr Ożarowski writes: > As I already suggested in my previous mail, installing scripts into > private directory and symlinking them in /usr/bin is the cleanest > solution IMHO Thank you. I have come to a compromise solution on this which builds on that suggestion. Ben

Re: Application libraries private, Distutils metadata available for console scripts and introspection

On 2 September 2015 at 20:35, Ben Finney wrote: > Ben Finney writes: > According to Robert's earlier message, that means the Distutils > metadata file needs to be not in the application's private directory, > but in a directory on

Re: Application libraries private, Distutils metadata available for console scripts and introspection

On Wed, Sep 02, 2015 at 09:06:01PM +1200, Robert Collins wrote: > > Ben Finney writes: > > > According to Robert's earlier message, that means the Distutils > > metadata file needs to be not in the application's private directory, > > but in a directory on the

Re: Application libraries private, Distutils metadata available for console scripts and introspection

Ben Finney writes: > How can I specify to Pybuild that an application should have its > modules all in a private namespace, but have the Distutils metadata > also available to `pkg_resources` queries? I've made a real, minimal example of a Debian package of a Python

Re: Application libraries private, Distutils metadata available for console scripts and introspection

> * The ‘--install-scripts’ option is *not* used, because Distutils places > the constructed scripts in the correct directory (‘/usr/bin/’) by > default. and that's why it doesn't work. As I already suggested in my previous mail, installing scripts into private directory and symlinking them

Re: Application libraries private, Distutils metadata available for console scripts and introspection

On 2 September 2015 at 22:45, Ben Finney wrote: > Robert Collins writes: > >> That private directory must be on the python search path when running >> the application (or the modules can't be imported). > > Not at all. The application's

Re: Application libraries private, Distutils metadata available for console scripts and introspection

On 2 September 2015 at 21:19, Karsten Hilbert wrote: > On Wed, Sep 02, 2015 at 09:06:01PM +1200, Robert Collins wrote: > >> > Ben Finney writes: >> >> > According to Robert's earlier message, that means the Distutils >> > metadata file

Re: Application libraries private, Distutils metadata available for console scripts and introspection

On Sep 02, 2015, at 09:06 PM, Robert Collins wrote: >So this is perhaps the disconnect: I did not say the metadata should >move: it should be in the private directory - it has to be adjacent to >the packages/modules its describing, since if it is present but the >package/module is not that is at

Re: Application libraries private, Distutils metadata available for console scripts and introspection

On Sep 02, 2015, at 11:19 AM, Karsten Hilbert wrote: >> That private directory must be on the python search path > >Maybe I'm a bit dense but isn't that what OP very much >DOESN'T want to _happen_ ? Not on the default sys.path, sure. But it has to get on sys.path at some point before the

Re: Application libraries private, Distutils metadata available for console scripts and introspection

Robert Collins writes: > That private directory must be on the python search path when running > the application (or the modules can't be imported). Not at all. The application's private modules are imported only via relative imports. -- \ “Free thought is a

Re: Application libraries private, Distutils metadata available for console scripts and introspection

On 1 September 2015 at 17:35, Ben Finney wrote: > Robert Collins writes: > >> PKG resources should find it anywhere in the python path. > > That's exactly the point, though. The packages are private to this > application, and should not be

Re: Application libraries private, Distutils metadata available for console scripts and introspection

Ben Finney writes: > The application has “console scripts” defined in the Distutils > `entry_points` mapping: > > $ cat ./setup.py > […] > entry_points={ > 'console_scripts': [ > "foo=FooApp.foo:main", > ], >

Re: Application libraries private, Distutils metadata available for console scripts and introspection

it just works, are you sure the script you're invoking is in the right dir? | mkdir -p /tmp/foo/bar /tmp/foo/bar.egg-info | cat >/tmp/foo/bar/__init__.py

Application libraries private, Distutils metadata available for console scripts and introspection

Howdy all, How can I specify to Pybuild that an application should have its modules all in a private namespace, but have the Distutils metadata also available to `pkg_resources` queries? I install its libraries to an application-specific space with `PYBUILD_INSTALL_ARGS =

Re: Application libraries private, Distutils metadata available for console scripts and introspection

PKG resources should find it anywhere in the python path. I'd the path correct within the all processes? On 1 Sep 2015 2:53 pm, "Ben Finney" wrote: > Howdy all, > > How can I specify to Pybuild that an application should have its modules > all in a private namespace,

Re: Application libraries private, Distutils metadata available for console scripts and introspection

Robert Collins writes: > PKG resources should find it anywhere in the python path. That's exactly the point, though. The packages are private to this application, and should not be available for import by other programs. On the other hand, the Distutils metadata (the