On 20 Apr, 2006, at 22:07, Martin v. Löwis wrote: > Guido van Rossum wrote: >> This is another area where API standardization is >> important; as soon as modules are loaded out of a zip file, the >> traditional approach of looking relative to os.path.dirname(__file__) >> no longer works. > > > 2. standardize on file names, not API. If I want to deploy > read-only data files, I put them into /usr/share. If I need > read-write files, I put them into /var. I did not have such > a problem yet on other systems, but I would also try to follow > the conventions of these systems. I don't think anyone mentioned this, but part of pkg_resources is an API for loading package-related data. That currently looks for data near the code, which makes Linux packagers unhappy but it should be possible to enhance pkg_resources to look in other locations (such as a directory below /usr/share/python) as well. The data loading API's is one feature of pkg_resources that would make it easier to locate data while at the same time storing data in locations that the various platforms proscribe without hardcoding such knowledge into every program. BTW. Please keep in mind that one of the major platforms for python doesn't have a proper package manager at all. OSX does have an installer application, but that's just that: a GUI for dropping files on you disk. There is no uninstaller, and no real dependency management. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available Url : http://mail.python.org/pipermail/python-dev/attachments/20080321/682e2404/attachment.bin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4