Chris McDonough <chrism <at> plope.com> writes: > >> That is not the definition of "resource" in setuptools-derived > >> systems. The definition of resource in setuptools-derived systems is > >> "a non-Python file that lives in a package", which is exactly the > >> opposite of the above definition. I'd suggest to avoid confusion we > >> don't call "files used by the project that must not be installed in > >> the same place that python modules or libraries", and we call this > >> other class of things something else.
Perhaps confusingly, in the distlib documentation I've used "resource" to mean what you've said above, i.e. the setuptools definition. Whatever they're called, though, I think we shouldn't dictate that all non-Python files have to live in some other location than a package. Definitely, we need to consider the needs of distro packagers, but we should not force one particular way of working on all users. For example, if someone's strategy involves an embedded Python, there's no need to make them live with some limitation designed to facilitate Linux distribution. Tarek hasn't also addressed the scenario of .zip-based deployment, which after all zipimport is there to support, and where there's no reason why read-only data files couldn't live in the zip along with the code that uses them. As to which approach to use in a given case, one can always document the criteria users should employ to arrive at the correct decision (e.g. considerations such as whether write access is needed). Regards, Vinay Sajip _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
