[Python-bugs-list] [ python-Feature Requests-588756 ] python should obey the FHS
SourceForge.net
noreply@sourceforge.net
Mon, 07 Jul 2003 20:37:10 -0700
Feature Requests item #588756, was opened at 2002-07-30 13:12
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=588756&group_id=5470
>Category: None
>Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: python should obey the FHS
Initial Comment:
[From: http://bugs.debian.org/134762]
FHS Compliance - .py{,c} are architecture independant
thus belong in /usr/share
The Python manual makes it clear that byte compiled
python files are
platform independant, and thus belong in
arch-independant packages and stored in /usr/share, as
per the FHS recommendations for such things.
So the request is to store them in
<prefix>/share/pythonX.Y.
----------------------------------------------------------------------
>Comment By: Brett Cannon (bcannon)
Date: 2003-07-07 20:37
Message:
Logged In: YES
user_id=357491
I think PYC files can be considered either libraries or data files.
Either way I am making this a feature request instead of a bug.
----------------------------------------------------------------------
Comment By: Adrian van den Dries (cantanker)
Date: 2003-06-18 16:32
Message:
Logged In: YES
user_id=209092
Did anyone bother *reading* the FHS?
http://www.pathname.com/fhs/2.2/fhs-4.7.html
> /usr/lib includes object files, libraries, and internal
binaries
http://www.pathname.com/fhs/2.2/fhs-4.11.html
> The /usr/share hierarchy is for all read-only architecture
independent data files.
.py{,c} files are *libraries*, not *data files*.
Thankyou, move along.
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2003-06-03 09:38
Message:
Logged In: YES
user_id=357491
It won't help with that request. Doing that would require changing install
paths as suggested below.
As for your questions about implementing --fhs-prefix, I can answer a few.
For Distutils questions you can just email python-dev to get the attention of
Distutils developers. For adding a second site-packages directory I am
against (use PYTHONPATH if that is needed).
----------------------------------------------------------------------
Comment By: Matthias Klose (doko)
Date: 2003-06-03 05:49
Message:
Logged In: YES
user_id=60903
PEP 304 addresses one part: the location of the generated
.py[co] files. I fail to see, how it adds support to put .py
files in /usr/share.
So it partly solves the problem.
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2003-05-20 21:38
Message:
Logged In: YES
user_id=357491
Will PEP 304 solve your problem?
----------------------------------------------------------------------
Comment By: Matthias Klose (doko)
Date: 2002-08-31 01:59
Message:
Logged In: YES
user_id=60903
Ok, I'll give --fhs-prefix a try. some questions:
- the lib_python in getpath.c hardcodes lib/pythonX.Y to
search for the libraries. Is it enouogh to set PYTHONPATH to
pythonX.Y?
- who to ask for distutils? are there concerns if a
module/library is splitted over two directories? Or should there
symlinks from /usr/lib/pythonX.Y to /usr/share/pythonX.Y?
- currently there is only one site-packages directory. how
should two site-packages be supported (lib and share)?
- speaking of etc: this is a configuration file and should belong
into the etc hierarchy. should etc be searched before or after
the library directories?
Python's include files: not all packages separate platform
specific headers from generic headers, probably therefore the
FHS puts them in /usr/include.
----------------------------------------------------------------------
Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 13:51
Message:
Logged In: YES
user_id=45365
The layouts are similar, but not the same. MacPython-OS9 uses the source tree layout, and Windows-Python too, IIRC.
MacPython-OSX in a framework build uses a normal layout, but in a very funny place, with lots of symlinks to make it behave like a framework. I would be very surprised if, say WinCE python or AS/400 python had anything resembling a unix layout. But all these layouts are similar enough that I've never come across a Python where I felt completely lost.
I think there's nothing wrong with enabling people to use their preferred layout, if they have a good reason for it, but I would be against enforcing it unless the advantages are clear and universal.
And someone has to do the work:-)
----------------------------------------------------------------------
Comment By: Gerhard Häring (ghaering)
Date: 2002-08-30 13:32
Message:
Logged In: YES
user_id=163326
Sorry, Matthias. I was confusing the FHS with the Linux
Standard Base.
----------------------------------------------------------------------
Comment By: Gerhard Häring (ghaering)
Date: 2002-08-30 13:24
Message:
Logged In: YES
user_id=163326
I assume that the Python directory layout is the same on all
currently supported platforms by Python. I really don't know
enough to be sure - the less that's true, the less my
following argument will be valid:
There are really two concerns:
1) make Python conform to the FHS
2) make Python behave the same cross-platform (Windows,
Unix, Mac, BeOS, OS/2, VMS, AS/400, ...)
You can't have both unless you force the FHS directory
layout onto all other platforms. I personally think that 2)
is a good thing.
I welcome the proposal of a configuration option to make
Python FHS-compliant, but I think it should not be the
default. Btw. you'd probably have to patch distutils, too.
Jack said that Pyhon include files should be cross-platform.
AFAIK they are, with one exceptions: pyconfig.h.
----------------------------------------------------------------------
Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 05:33
Message:
Logged In: YES
user_id=45365
Well... the usual way in which people implemented sharing between
architectures was that the /usr/share hierarchy duplicated the other
hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross-
platform from an nfs server. That's the architecture the Python install
was created for. I have no idea why FHS modified this test-and-tried
layout that's been in use for at least 15 years.
But: if you really want the other layout, why not submit a fix to
configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/
share and if that option is present override the Makefile.pre.in
declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR?
(Hmm, coming to think of it: it seems rather silly that the FHS puts
include files into /usr/include, where they aren't shared... If there's one
thing that can be crossplatform it's source code....)
----------------------------------------------------------------------
Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 05:33
Message:
Logged In: YES
user_id=45365
Well... the usual way in which people implemented sharing between
architectures was that the /usr/share hierarchy duplicated the other
hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross-
platform from an nfs server. That's the architecture the Python install
was created for. I have no idea why FHS modified this test-and-tried
layout that's been in use for at least 15 years.
But: if you really want the other layout, why not submit a fix to
configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/
share and if that option is present override the Makefile.pre.in
declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR?
(Hmm, coming to think of it: it seems rather silly that the FHS puts
include files into /usr/include, where they aren't shared... If there's one
thing that can be crossplatform it's source code....)
----------------------------------------------------------------------
Comment By: Matthias Klose (doko)
Date: 2002-08-30 04:30
Message:
Logged In: YES
user_id=60903
when configured with --prefix=/usr/share and
--exec-prefix=/usr, python installs the header files into
/usr/share/include/pythonX.Y, which is at least unusual.
According to the FHS these files should go into
/usr/include/pythonX.Y
----------------------------------------------------------------------
Comment By: Matthias Klose (doko)
Date: 2002-08-30 03:52
Message:
Logged In: YES
user_id=60903
Not yet.
--prefix=/foo/share/pythonX.Y would lead to
/foo/share/pythonX.Y/lib/pythonX.Y.
The SCRIPTDIR is somewhat hardcoded in getpath.c. So it's
not possible
to install into /foo/share/pythonX.Y, only
/foo/share/lib/pythonX.Y is supported.
The FHS doesn't specify where to put files inside
/usr/share, but most distributions put application specific
files directly in /usr/share.
----------------------------------------------------------------------
Comment By: Jack Jansen (jackjansen)
Date: 2002-08-30 01:35
Message:
Logged In: YES
user_id=45365
I'm confused. If you configure with --exec-prefix=/foo --prefix=/foo/share/pythonX.Y isn't that good enough?
If it's good enough (i.e. if it allows you to build a Python that adheres to the FHS if you are so inclined) that I agree with ghaering: there's no reason to force people to adhere to the Filesystem Hierarchy Standard, so let's close the bug.
If it is impossible to make an FHS-compliant distribution with the current setup: please explain.
----------------------------------------------------------------------
Comment By: Matthias Klose (doko)
Date: 2002-08-29 23:57
Message:
Logged In: YES
user_id=60903
The reason given to close the report seems to be invalid.
The FHS has nothing to with Debian (except that we follow
the FHS). The FHS is targeted at Unix distributions, so it's
neither limited to a single distribution nor to Linux
distributions in general.
----------------------------------------------------------------------
Comment By: Gerhard Häring (ghaering)
Date: 2002-08-25 05:41
Message:
Logged In: YES
user_id=163326
Python runs on dozens of platforms besides Debian Linux.
Thus the Linux FHS shouldn't concern Python at all. I'd
propose to close this bug as "Invalid".
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 04:13
Message:
Logged In: YES
user_id=21627
I think this requires a PEP. A Python package can consist of
byte code modules and extension modules; arranging the
package loader to find those in different directories is a
challenge.
----------------------------------------------------------------------
Comment By: Matthias Klose (doko)
Date: 2002-07-30 13:15
Message:
Logged In: YES
user_id=60903
FHS: Filesystem Hierarchy Standard
http://www.pathname.com/fhs/
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=588756&group_id=5470