Le mercredi 01 octobre 2008 à 19:59 -0400, Phillip J. Eby a écrit :
> >locale/{message catalogs for various languages} -- These are binary
> >files that contain strings that the user may see when a message is
> >given. These, I think are data.
>
> I lean the other way, since they're not editable.
Locale data should be shipped in standard form, in /usr/share/locale.
Again, Python is not the only thing you need to think of. Not only, if
you don’t use standard gettext catalogs, you are breaking translation
tools, but if you don’t ship them at the standard location, you are
breaking tools like localepurge (or anything that cleans up the
filesystem based on standard file locations).
> Keep in mind that
> some platforms have no "locale" directories as such, and thus trying
> to support multiple locations thereof is a burden for cross-platform
> app developers, vs. simply treating them as internal resources.
No, you are making the burden heavier for Linux platforms by trying to
be more portable. There is no reason why you can’t define a locale
directory on platforms where it does not exist, but when it exists a
standards document defining where files go, you must follow it. Any time
you don’t follow it, we consider it a serious breakage and we have to
patch the code anyway.
> >templates/*html -- These are templates that the application fills in
> >with variables intermixed with short bits of code.
[snip]
> >My leaning is that these are data.
>
> If you follow this logic (create bytecode from it, can't run w/out
> interp or compiler), then any .py file is *also* data; i.e., this
> Does Not Follow.
Sorry, but things don’t work this way. Anything that is *not* a .py file
should not land in the python module directories. This is utter abuse of
a loophole of the implementation, and I can’t think of another language
that allows that. You will not find anything else than perl modules in
the perl modules directories. You will not find anything else than C#
modules in the Mono modules directory. And so on.
> >static/{javascript,css,images} -- These are things that are definitely
> >never executed. They are served by the webserver verbatim when their
> >URL is called. These are certainly data. (Note: I don't believe these
> >are referenced using the resources API, just via URL.)
>
> Uh... that would depend entirely on the library or application. But
> if they're static and the user's got no business tinkering with them,
> then it's a resource.
No, again it is insane to ship them as resources. These are files that
need to be accessed directly by the webserver, and as such they need to
be shipped in a data directory, not in a python modules directory.
> >So... do you agree on which of these are data and which are resources?
> >Do you have an idea on how we can prevent application and framework
> >writers from misusing the resources API to load things that are data?
>
> Apparently not. The alternative I would suggest is that under the
> new standard, an install tool should be allowed to relocate any
> non-Python files, and all access has to go through a resource
> API. The install tool would then have to be responsible for putting
> some kind of forwarding information in the package directory to tell
> the resource API where it squirrelled the file(s) off to. Then we
> can avoid all this angels-on-a-pin argument and the distros can Have
> It Their Way[tm].
I don’t understand why you want to make it so complicated. All you need
is a way to specify directories where different kinds of files land and
a simple API to retrieve the file names/contents. Then, you can ship the
files at the place you like in eggs, and we can ship the files at the
standard places in our packages.
Cheers,
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
signature.asc
Description: Ceci est une partie de message numériquement signée
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
