Re: [Python-Dev] Python and the Linux Standard Base (LSB)
At 01:05 PM 11/28/2006 -0800, Guido van Rossum wrote:
On 11/28/06, Barry Warsaw barry@python.org wrote:
There's a related issue that may or may not be in scope for this thread. For distros like Gentoo or Ubuntu that rely heavily on their own system Python for the OS to work properly, I'm quite loathe to install Cheeseshop packages into the system site-packages.
I wonder if would help if we were to add a vendor-packages directory where distros can put their own selection of 3rd party stuff they depend on, to be searched before site-packages, and a command-line switch that ignores site-package but still searches vendor-package. (-S would almost do it but probably suppresses too much.)
They could also use -S and then explicitly insert the vendor-packages directory into sys.path at the beginning of their scripts. And a .pth in site-packages could add vendor-packages at the *end* of sys.path, so that scripts not using -S would pick it up.
This would be backward compatible except for the vendor scripts that want to use this approach.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Nov 28, 2006, at 4:19 PM, Phillip J. Eby wrote:
At 01:05 PM 11/28/2006 -0800, Guido van Rossum wrote:
On 11/28/06, Barry Warsaw barry@python.org wrote:
There's a related issue that may or may not be in scope for this thread. For distros like Gentoo or Ubuntu that rely heavily on
their
own system Python for the OS to work properly, I'm quite loathe to install Cheeseshop packages into the system site-packages.
I wonder if would help if we were to add a vendor-packages directory where distros can put their own selection of 3rd party stuff they depend on, to be searched before site-packages, and a command-line switch that ignores site-package but still searches vendor-package. (-S would almost do it but probably suppresses too much.)
They could also use -S and then explicitly insert the vendor- packages directory into sys.path at the beginning of their scripts.
Possibly, but stuff like this can be a pain because your dependent app must build in the infrastructure itself to get the right paths set up for its scripts. An approach I've used in the past is to put a paths.py file in the bin directory and force every script to "import paths" before it imports anything it doesn't want to get from the stdlib (including overrides). paths.py is actually generated though because the user could specify an alternative Python with a configure switch.
What I'm moving to now though is a sort of 'shell' or driver script which does that path setup once, then imports a module based on argv [0], sniffing out a main() and then calling that. The trick then of course is that you symlink all the top-level user scripts to this shell. Works fine if all you care about is *nix <wink>, but it does mean an application with lots of entry-level scripts has to build all this infrastructure itself.
Maybe there's no better way of doing this and applications are best left to their own devices. But in the back of my mind, I keep thinking there should be a better way. ;)
- -Barry
At 06:41 PM 11/28/2006 -0500, Barry Warsaw wrote:
On Nov 28, 2006, at 4:19 PM, Phillip J. Eby wrote:
At 01:05 PM 11/28/2006 -0800, Guido van Rossum wrote:
On 11/28/06, Barry Warsaw barry@python.org wrote:
There's a related issue that may or may not be in scope for this thread. For distros like Gentoo or Ubuntu that rely heavily on
their
own system Python for the OS to work properly, I'm quite loathe to install Cheeseshop packages into the system site-packages.
I wonder if would help if we were to add a vendor-packages directory where distros can put their own selection of 3rd party stuff they depend on, to be searched before site-packages, and a command-line switch that ignores site-package but still searches vendor-package. (-S would almost do it but probably suppresses too much.)
They could also use -S and then explicitly insert the vendor- packages directory into sys.path at the beginning of their scripts.
Possibly, but stuff like this can be a pain because your dependent app must build in the infrastructure itself to get the right paths set up for its scripts. ... Maybe there's no better way of doing this and applications are best left to their own devices. But in the back of my mind, I keep thinking there should be a better way. ;)
Well, you can always use setuptools, which generates script wrappers that import the desired module and call a function, after first setting up sys.path. :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Nov 28, 2006, at 7:10 PM, Phillip J. Eby wrote:
Well, you can always use setuptools, which generates script wrappers that import the desired module and call a function, after first setting up sys.path. :)
That's so 21st Century! Where was setuptools back in 1996? :) Seriously though, that does sound cool, and thanks for the tip.
- -Barry
participants (2)
-
Barry Warsaw -
Phillip J. Eby