Gregory Ewing <greg.ew...@canterbury.ac.nz> writes: > Ben Finney wrote: > > On systems conforming to the Filesystem Hierarchy Standard, it's > > forbidden: programs go in a platform-specific location > > <URL:http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA>, > > while platform-independent data files go in a separate location > > <URL:http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA>. > > But Python code itself is platform-independent, so it should count as > data for the purposes of the FHS, shouldn't it?
True in most cases, but not all (think extension modules, compiled to architecture-specific bytecode). But you're right, I over-simplified. The FHS specifies that the first location isn't only for platform-specific files, but is also for “object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts”. The second location is for “all read-only architecture independent data files” (where the context makes it clear that “data files” is exclusive of program files). So, whether Python bytecode is platform-specific or not, it is relegated by the FHS to a separate location from data files. The separation requirement remains, and Python's distutils doesn't support it. What Python facilities do we have for supporting both install-time decisions about package install layout, and run-time requirements to find the files wherever they were installed? -- \ “Two paradoxes are better than one; they may even suggest a | `\ solution.” —Edward Teller | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
