[Python-Dev] Python and the Linux Standard Base (LSB) (original) (raw)
Robin Bryce robinbryce at gmail.com
Thu Nov 30 03:01:56 CET 2006
- Previous message: [Python-Dev] Python and the Linux Standard Base (LSB)
- Next message: [Python-Dev] Python and the Linux Standard Base (LSB)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 28/11/06, "Martin v. Löwis" <martin at v.loewis.de> wrote:
I personally agree that "Linux standards" should specify a standard layout for a Python installation, and that it should be the one that "make install" generates (perhaps after "make install" is adjusted). Whether or not it is the LSB that needs to specify that, I don't know, because the LSB does not specify a file system layout. Instead, it incorporates the FHS - which might be the right place to define the layout of a Python installation. For the LSB, it's more import that "import httplib" gives you something working, no matter where httplib.py comes from (or whether it comes from httplib.py at all).
Yes, especially with the regard to the level you pitch for LSB. I would go as far as to say that if this "contract in spirit" is broken by vendor repackaging they should:
- Call the binaries something else because it is NOT python any more.
- Setup the installation layout so that it does NOT conflict or overlap with the standard layout.
- Call the whole package something else.
But I can't see that happening.
Is it a bad idea to suggest that: Python grows a vendor_variant attribute somewhere in the standard lib; That its content is completely dictated by a new ./configure argument which is the empty string by default; And, request that it is left empty by re-packagers if the installation is 'reasonably standard' ?
I would strongly prefer not write code that is conditional on such an attribute. However if there was a clear way for a vendor to communicate "This is not a standard python runtime" to the python run time, early failure (in the application) with informative error messages becomes much more viable.
Eg sys.vendor_variant would be orthogonal to sys.version and sys.version_info
Given: python -c "import sys; print sys.version" GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
A regex on sys.version does not seem like a good way to get positive confirmation I'm using the "Canonical" variant (pun intended)
python -c "from distutils.util import get_platform; print get_platform()" Tells me nothing about the vendor of my linux distribution. Except, ironically, when it says ImportError
Cheers, Robin
- Previous message: [Python-Dev] Python and the Linux Standard Base (LSB)
- Next message: [Python-Dev] Python and the Linux Standard Base (LSB)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]