Re: [Distutils] distlib and data files = resources ?
I'd be expecting these files under /usr/share/appname and being read only... I don't agree with Data files should never be installed to package directories... LFHS is not a religion. I can see cases where is not appropriate. The main difference could be a library vs an application case: they have clearly different requirements (so I'm expecting the application global config files to be under /etc). Someone mentioned different scenarios (app vs library, user vs system integrator vs developer etc I hope this helps Thanks Antonio On Wed 21/11/12 04:21, PJ Eby p...@telecommunity.com wrote: On Tue, Nov 20, 2012 at 3:18 AM, Ronald Oussoren wrote: On 19 Nov, 2012, at 20:26, PJ Eby wrote: Data files should never be installed to package directories. But Im not aware of any good reason why resource files should ever be installed anywhere *else*. To be (too) snarky: because the FHS says so. Less snarky, Linux distributors try to keep simular files together (for example storing all gettext translations together in /usr/share/locale). To play nice in such an enviroment Python packages would have to install resource files outside of the python package and into the FHS specified directory structure. Consider the example of a web page template containing embedded Python code. Is that a data file containing code, or a code file containing data? Where does the FHS say it goes? What if its not embedded Python, but an embedded DSL interpreted by the package it goes with? What if its not a page template, but a precompiled SQL grammar? (Such as was distributed with the gadfly package, many a year ago.) These are the kind of files I mean by resources. If somebody wants to support gettext or similar localization, then obviously they should declare the files data -- or better yet, as part of an explicit localization category. The whole point of resources is that its a catch-all for static data thats more convenient to treat as a standalone source file than to inline as a huge triple-quoted constant in a .py file. ;-) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
On 19 Nov, 2012, at 20:26, PJ Eby p...@telecommunity.com wrote: Data files should never be installed to package directories. But I'm not aware of any good reason why resource files should ever be installed anywhere *else*. To be (too) snarky: because the FHS says so. Less snarky, Linux distributors try to keep simular files together (for example storing all gettext translations together in /usr/share/locale). To play nice in such an enviroment Python packages would have to install resource files outside of the python package and into the FHS specified directory structure. That again would mean there needs to be an API to access such files because it is not always necessary to store resources separate from their python package and because the FHS linux specific. Storing resource files outside of packages directories seems to be only relevant for software that's packaged by a Linux distribution, not for python packages installed into a virtualenv or on other platforms. Ronald ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
Can you think of any such *besides* documentation? 'Cause if documentation is the only thing, then we should just call it that. ;-) :-) No, to be honest, I can't. But I'm not an expert - the Linux distro people probably know a lot better than I do what types of files give them trouble. But if documentation's the only case then yes, definitely call it that. Those come to my mind: data files needed by self-tests. Custom theming stylesheets. Default configuration files which you need to copy at the first start to user's config. Templates for reports your package is generating. cheers, vaclav ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
On 11/20/2012 3:18 AM, Ronald Oussoren wrote: Storing resource files outside of packages directories seems to be only relevant for software that's packaged by a Linux distribution, not for python packages installed into a virtualenv or on other platforms. I would say this is the central point of the issue. I'd add that installing files outside of package directories may be desirable when installing into an installed python's site-packages. This might be when using setup.py install, or when using a system installer. Also remember that there maybe be multiple locations involved: image 2 different buildouts, using the same python, with different versions of the same package. Also, there may be multiple python installations, each with its own site-packages. You wouldn't necessarily want either of those writing files to /etc, for example. So it seems to me you'd want this to be an install-time option: install this library in a given location, but don't write files outside of site-packages, or install this library in a given location, but do write files outside of site-packages. The given location might be in a virtualenv, a buildout, the system python's site-packages, or some other python's site-packages. I realize that for some systems, site-packages isn't the correct term, but it's close enough. I use it to mean some place on sys.path that will be searched by default, for a given python installation. -- Eric. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
On 19.11.2012 23:46, PJ Eby wrote: On Mon, Nov 19, 2012 at 2:37 PM, Paul Moore p.f.mo...@gmail.com wrote: +1. But there's a third type of file, which is worth listing separately, just to clarify: * ??? files: constant files that are *not* typically used at runtime (documentation, for example) Maybe support files would be a good name? Can you think of any such *besides* documentation? 'Cause if documentation is the only thing, then we should just call it that. ;-) Examples, snippets etc. HTH Niki ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
On Nov 20, 2012, at 09:18 AM, Ronald Oussoren wrote: To be (too) snarky: because the FHS says so. Less snarky, Linux distributors try to keep simular files together (for example storing all gettext translations together in /usr/share/locale). To play nice in such an enviroment Python packages would have to install resource files outside of the python package and into the FHS specified directory structure. That again would mean there needs to be an API to access such files because it is not always necessary to store resources separate from their python package and because the FHS linux specific. Storing resource files outside of packages directories seems to be only relevant for software that's packaged by a Linux distribution, not for python packages installed into a virtualenv or on other platforms. We talked about this quite a bit a few Pycons ago. This is where the idea of categories of files came up, where you could designate certain files as configuration files, documentation, etc. Then there would be a default mapping of these categories to locations. virtualenv installations would use one mapping, while distros could define a different mapping. Linux distros could probably share the FHS mapping for such categories. I don't know whatever became of this, but I remember at time it seemed to nicely solve our (i.e. Debian/Ubuntu, and IIRC Fedora/RH) needs. Cheers, -Barry ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
Bento uses these categories by default and lets you define your own. If requested by the package, it writes the install-time prefixes to a per-package .py file with NAME=value lines. - prefix: install architecture-independent files - eprefix: install architecture-dependent files - bindir: user executables - sbindir: system admin executables - libexecdir: program executables - sysconfdir: read-only single-machine data - sharedstatedir: modifiable architecture-independent data - localstatedir: modifiable single-machine data - libdir: object code libraries - includedir: C header files - oldincludedir: C header files for non-gcc - datarootdir: read-only arch.-independent data root - datadir: read-only architecture-independent data - infodir: info documentation - localedir: locale-dependent data - mandir: man documentation - docdir: documentation root - htmldir: html documentation - dvidir: dvi documentation - pdfdir: pdf documentation - psdir: ps documentation ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
On Nov 20, 2012, at 04:51 PM, Daniel Holth wrote: Bento uses these categories by default and lets you define your own. If requested by the package, it writes the install-time prefixes to a per-package .py file with NAME=value lines. The key thing about the categories idea is that distro maintainers can define the mappings that make sense for packages built and installed for their policies. E.g. most Linux distros would probably have some FHS mapping. So the package would only claim files are of a certain category, and where that actually ends up depends on what environment the package is installed into, e.g. Debian, Fedora, MacPorts, virtualenv, etc. -Barry signature.asc Description: PGP signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
On Tue, Nov 20, 2012 at 3:18 AM, Ronald Oussoren ronaldousso...@mac.comwrote: On 19 Nov, 2012, at 20:26, PJ Eby p...@telecommunity.com wrote: Data files should never be installed to package directories. But I'm not aware of any good reason why resource files should ever be installed anywhere *else*. To be (too) snarky: because the FHS says so. Less snarky, Linux distributors try to keep simular files together (for example storing all gettext translations together in /usr/share/locale). To play nice in such an enviroment Python packages would have to install resource files outside of the python package and into the FHS specified directory structure. Consider the example of a web page template containing embedded Python code. Is that a data file containing code, or a code file containing data? Where does the FHS say it goes? What if it's not embedded Python, but an embedded DSL interpreted by the package it goes with? What if it's not a page template, but a precompiled SQL grammar? (Such as was distributed with the gadfly package, many a year ago.) These are the kind of files I mean by resources. If somebody wants to support gettext or similar localization, then obviously they should declare the files data -- or better yet, as part of an explicit localization category. The whole point of resources is that it's a catch-all for static data that's more convenient to treat as a standalone source file than to inline as a huge triple-quoted constant in a .py file. ;-) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/20/2012 10:21 PM, PJ Eby wrote: On Tue, Nov 20, 2012 at 3:18 AM, Ronald Oussoren ronaldousso...@mac.comwrote: On 19 Nov, 2012, at 20:26, PJ Eby p...@telecommunity.com wrote: Data files should never be installed to package directories. But I'm not aware of any good reason why resource files should ever be installed anywhere *else*. To be (too) snarky: because the FHS says so. Less snarky, Linux distributors try to keep simular files together (for example storing all gettext translations together in /usr/share/locale). To play nice in such an enviroment Python packages would have to install resource files outside of the python package and into the FHS specified directory structure. Consider the example of a web page template containing embedded Python code. Is that a data file containing code, or a code file containing data? Where does the FHS say it goes? What if it's not embedded Python, but an embedded DSL interpreted by the package it goes with? What if it's not a page template, but a precompiled SQL grammar? (Such as was distributed with the gadfly package, many a year ago.) These are the kind of files I mean by resources. If somebody wants to support gettext or similar localization, then obviously they should declare the files data -- or better yet, as part of an explicit localization category. The whole point of resources is that it's a catch-all for static data that's more convenient to treat as a standalone source file than to inline as a huge triple-quoted constant in a .py file. ;-) Exactly: any dsitribution-packaer who tries to move such files out of the package due to some misunderstood FHS-driven theory about such files is just breaking the software to no purpose. - -1 to enabling such misuse, as distinct from data / config files which fall into other categories (documentation, example configs, etc.). Such files are not resources in any sensible use of the term. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCsTmsACgkQ+gerLs4ltQ4uBgCgnRRaQA0AjzaNOqPomSHOC7+s 19cAoMUl4FwpW6TDMAqSjG1Cj3bYx6bv =w8D1 -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
On Sun, Nov 18, 2012 at 6:40 PM, Vinay Sajip vinay_sa...@yahoo.co.ukwrote: 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. Indeed. The setuptools resource definition, btw, is intended to parallel Java's and Windows'. Java resources are not data, they are part of the code. Same thing for Windows resources. In both cases, they are embedded in executables (jars for java, exe's and dlls for windows). Such resource files are not really data, and flat out don't belong in /etc, /var, /usr/share, or any other such locations, any more than icons in a Java jar should be extracted and placed elsewhere. The confusion that exists right now about data files stems from the fact that distutils data files system really was originally intended for *actual* data, that *should* be installed to non-library locations. However, for people who needed resources, there was a widespread distutils hack that abused the data_files key to install resources - a hack which setuptools adopted, improved upon (as package_data), and was then adopted back into distutils for Python 2.4. If I'd realized this confusion would be happening several years later, I'd have dubbed that key package_resources, but at the time, it was the logical-seeming name because of the already-widespread distutils hack. (The resource_* APIs came later.) I think we should use some clearly-distinct (and mutually exclusive) terminology going forward: * Data files: stuff the user can and/or should change, such as configuration files, startup databases, etc. * Resource files: constant files used at runtime, regardless of file type Data files should never be installed to package directories. But I'm not aware of any good reason why resource files should ever be installed anywhere *else*. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
On 19 November 2012 19:26, PJ Eby p...@telecommunity.com wrote: I think we should use some clearly-distinct (and mutually exclusive) terminology going forward: * Data files: stuff the user can and/or should change, such as configuration files, startup databases, etc. * Resource files: constant files used at runtime, regardless of file type Data files should never be installed to package directories. But I'm not aware of any good reason why resource files should ever be installed anywhere *else*. +1. But there's a third type of file, which is worth listing separately, just to clarify: * ??? files: constant files that are *not* typically used at runtime (documentation, for example) Maybe support files would be a good name? Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
On Mon, Nov 19, 2012 at 2:37 PM, Paul Moore p.f.mo...@gmail.com wrote: On 19 November 2012 19:26, PJ Eby p...@telecommunity.com wrote: I think we should use some clearly-distinct (and mutually exclusive) terminology going forward: * Data files: stuff the user can and/or should change, such as configuration files, startup databases, etc. * Resource files: constant files used at runtime, regardless of file type Data files should never be installed to package directories. But I'm not aware of any good reason why resource files should ever be installed anywhere *else*. +1. But there's a third type of file, which is worth listing separately, just to clarify: * ??? files: constant files that are *not* typically used at runtime (documentation, for example) Maybe support files would be a good name? Can you think of any such *besides* documentation? 'Cause if documentation is the only thing, then we should just call it that. ;-) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
On 19 November 2012 21:46, PJ Eby p...@telecommunity.com wrote: On Mon, Nov 19, 2012 at 2:37 PM, Paul Moore p.f.mo...@gmail.com wrote: On 19 November 2012 19:26, PJ Eby p...@telecommunity.com wrote: I think we should use some clearly-distinct (and mutually exclusive) terminology going forward: * Data files: stuff the user can and/or should change, such as configuration files, startup databases, etc. * Resource files: constant files used at runtime, regardless of file type Data files should never be installed to package directories. But I'm not aware of any good reason why resource files should ever be installed anywhere *else*. +1. But there's a third type of file, which is worth listing separately, just to clarify: * ??? files: constant files that are *not* typically used at runtime (documentation, for example) Maybe support files would be a good name? Can you think of any such *besides* documentation? 'Cause if documentation is the only thing, then we should just call it that. ;-) :-) No, to be honest, I can't. But I'm not an expert - the Linux distro people probably know a lot better than I do what types of files give them trouble. But if documentation's the only case then yes, definitely call it that. Paul. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
Tarek Ziadé tarek at ziade.org writes: and I thought I should bring up that distutils2 has implemented a way to define data files that can be installed in the right places on the target system. right here being what the linux distros decides, or the default win location etc. There is a description here: http://alexis.notmyidea.org/distutils2/setupcfg.html#resources I think it's a better system than the data files that are located/and stay in the python package, maybe it would be interesting not to lose it. I would agree that it shouldn't be lost, but there are some scenarios where data located in packages might be desirable - perhaps, for example, - translation files (.mo) - templates Particularly where these relate to plugins of some sort. At the moment distlib functionality is lower-level than pysetup, so I haven't looked at these issues in detail yet. However, I agree that an important element is the mapping of logical paths to physical paths in a standardised but extensible way which is distro packager friendly and also sensible on Windows/ OS X. Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
On 11/18/12 10:15 PM, Vinay Sajip wrote:
Tarek Ziadé tarek at ziade.org writes:
and I thought I should bring up that distutils2 has implemented a way to
define data files that can be installed in the right places on the
target system. right here being what the linux distros decides, or the
default win location etc.
There is a description here:
http://alexis.notmyidea.org/distutils2/setupcfg.html#resources
I think it's a better system than the data files that are located/and
stay in the python package, maybe it would be interesting not to lose it.
I would agree that it shouldn't be lost, but there are some scenarios where data
located in packages might be desirable - perhaps, for example,
- translation files (.mo)
- templates
Those two examples have usually a specific location on the various linux
distros.
Particularly where these relate to plugins of some sort.
Having a indirection like distutils2's resources allows the data files
to live alongside the code
in development and to be installed wherever that's desired by the
distro, without breaking
the code as long as it uses the indirection function to find back the file.
Since the indirection is provided by a file that can be browsed in the
metadata directory,
it means anyone can get the file location by using the API we provided.
e.g.
get_file_path('ProjectName', 'relative/path/file.mo')
see
http://hg.python.org/distutils2/file/65e23cccd0db/distutils2/database.py#l595
At the moment distlib functionality is lower-level than pysetup, so I haven't
looked at these issues in detail yet. However, I agree that an important element
is the mapping of logical paths to physical paths in a standardised but
extensible way which is distro packager friendly and also sensible on Windows/
OS X.
That's been an issue for OS packagers since day 1, so it would be great
if we solve this in this round of new tools :)
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
Tarek Ziadé tarek at ziade.org writes: Having a indirection like distutils2's resources allows the data files to live alongside the code in development and to be installed wherever that's desired by the distro, without breaking the code as long as it uses the indirection function to find back the file. Since the indirection is provided by a file that can be browsed in the metadata directory, it means anyone can get the file location by using the API we provided. Yes, but it seems like you're assuming everything's always installed in a conventional way and not, say, deployed in a .zip. I'm not disputing what you said - get_file_path and get_resource_path are still there in distlib - but I'm not sure that there's *never* a case for data located in packages. Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
On 11/18/2012 05:08 PM, Vinay Sajip wrote: Tarek Ziadé tarek at ziade.org writes: Having a indirection like distutils2's resources allows the data files to live alongside the code in development and to be installed wherever that's desired by the distro, without breaking the code as long as it uses the indirection function to find back the file. Since the indirection is provided by a file that can be browsed in the metadata directory, it means anyone can get the file location by using the API we provided. Yes, but it seems like you're assuming everything's always installed in a conventional way and not, say, deployed in a .zip. I'm not disputing what you said - get_file_path and get_resource_path are still there in distlib - but I'm not sure that there's *never* a case for data located in packages. Requiring that developers build an alternate-structure-of-files-that-arent-Python-files-just-because-they-aren't-Python-files outside the package structure seems like a terrible idea. - C ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
Just come to my mind data test related to a package would be a natural candidate: mypack |- __init__.py |- test |- __init__.py |- test0.py |- data |- data.for.test0.dat It is natural deploying them as part of an installer file. I don't see why another indirection layer is required here: you have the test.__file__ or the inspect.getfile *already*. What makes so special this case or a very similar one (eg. po files, images files for a gui based app, etc.)? Is there any reason to invent/introduce something else? I hope this helps, Antonio Vinay Sajip wrote: Tarek Ziadétarekat ziade.org writes: Having a indirection like distutils2's resources allows the data files to live alongside the code in development and to be installed wherever that's desired by the distro, without breaking the code as long as it uses the indirection function to find back the file. Since the indirection is provided by a file that can be browsed in the metadata directory, it means anyone can get the file location by using the API we provided. Yes, but it seems like you're assuming everything's always installed in a conventional way and not, say, deployed in a .zip. I'm not disputing what you said - get_file_path and get_resource_path are still there in distlib - but I'm not sure that there's *never* a case for data located in packages. Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
On 11/18/12 11:15 PM, Chris McDonough wrote: On 11/18/2012 05:08 PM, Vinay Sajip wrote: Tarek Ziadé tarek at ziade.org writes: Having a indirection like distutils2's resources allows the data files to live alongside the code in development and to be installed wherever that's desired by the distro, without breaking the code as long as it uses the indirection function to find back the file. Since the indirection is provided by a file that can be browsed in the metadata directory, it means anyone can get the file location by using the API we provided. Yes, but it seems like you're assuming everything's always installed in a conventional way and not, say, deployed in a .zip. I'm not disputing what you said - get_file_path and get_resource_path are still there in distlib - but I'm not sure that there's *never* a case for data located in packages. Requiring that developers build an alternate-structure-of-files-that-arent-Python-files-just-because-they-aren't-Python-files outside the package structure seems like a terrible idea. I think you did not get it. If you look/read carefully, it's not an alternate structure. The files are not moved - they are staying at the same place alongside the Python files in your source tree. The difference is only at installation time: they may be installed somewhere else. And when you access them - there's an API to read them instead of using __file__. Tarek ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
On 11/18/12 11:25 PM, Antonio Cavallo wrote: Just come to my mind data test related to a package would be a natural candidate: mypack |- __init__.py |- test |- __init__.py |- test0.py |- data |- data.for.test0.dat It is natural deploying them as part of an installer file. I don't see why another indirection layer is required here: you have the test.__file__ or the inspect.getfile *already*. What makes so special this case or a very similar one (eg. po files, images files for a gui based app, etc.)? Is there any reason to invent/introduce something else? One example: - if you include test that means you want test to be run - your test writes in that .dat file what happens in distros that have a read-only site-packages and only allow writes under /var/xxx ? if you define all your data files under some categories, suddenly, you are allowing OS packagers to tweak your package config to move these files to another spot, without having to change your package's code. Today, OS packagers will patch your code. I hope this helps, Antonio Vinay Sajip wrote: Tarek Ziadétarekat ziade.org writes: Having a indirection like distutils2's resources allows the data files to live alongside the code in development and to be installed wherever that's desired by the distro, without breaking the code as long as it uses the indirection function to find back the file. Since the indirection is provided by a file that can be browsed in the metadata directory, it means anyone can get the file location by using the API we provided. Yes, but it seems like you're assuming everything's always installed in a conventional way and not, say, deployed in a .zip. I'm not disputing what you said - get_file_path and get_resource_path are still there in distlib - but I'm not sure that there's *never* a case for data located in packages. Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
On 11/18/2012 05:33 PM, Tarek Ziadé wrote: On 11/18/12 11:15 PM, Chris McDonough wrote: On 11/18/2012 05:08 PM, Vinay Sajip wrote: Tarek Ziadé tarek at ziade.org writes: Having a indirection like distutils2's resources allows the data files to live alongside the code in development and to be installed wherever that's desired by the distro, without breaking the code as long as it uses the indirection function to find back the file. Since the indirection is provided by a file that can be browsed in the metadata directory, it means anyone can get the file location by using the API we provided. Yes, but it seems like you're assuming everything's always installed in a conventional way and not, say, deployed in a .zip. I'm not disputing what you said - get_file_path and get_resource_path are still there in distlib - but I'm not sure that there's *never* a case for data located in packages. Requiring that developers build an alternate-structure-of-files-that-arent-Python-files-just-because-they-aren't-Python-files outside the package structure seems like a terrible idea. I think you did not get it. If you look/read carefully, it's not an alternate structure. The files are not moved - they are staying at the same place alongside the Python files in your source tree. The difference is only at installation time: they may be installed somewhere else. And when you access them - there's an API to read them instead of using __file__. I don't really take exception to having such a feature (although I would be unlikely to use it), but I do take exception to the first paragraph of the description you pointed at: This section describes the files used by the project which must not be installed in the same place that python modules or libraries, they are called resources. They are for example documentation files, script files, databases, etc... 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. - C ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
On 11/18/12 11:45 PM, Chris McDonough wrote: I don't really take exception to having such a feature (although I would be unlikely to use it), but I do take exception to the first paragraph of the description you pointed at: This section describes the files used by the project which must not be installed in the same place that python modules or libraries, they are called resources. They are for example documentation files, script files, databases, etc... 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. I think there's a difference between: 1/ the nature of the file = e.g. not a source code file but a data file 2/ the location of the file = in site-packages as opposed to anywhere else The name resource for me is only defined by 1/ and I don't see any confusion or opposed definitions in that naming. Neither did the people that worked on this feature. But if you feel it's confusing, I am all for a separate name - I can't think of another one though, do you have one in mind ? 'data' seems to much generic... Tarek ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distlib and data files = resources ?
On 11/18/2012 05:55 PM, Tarek Ziadé wrote: On 11/18/12 11:45 PM, Chris McDonough wrote: I don't really take exception to having such a feature (although I would be unlikely to use it), but I do take exception to the first paragraph of the description you pointed at: This section describes the files used by the project which must not be installed in the same place that python modules or libraries, they are called resources. They are for example documentation files, script files, databases, etc... 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. I think there's a difference between: 1/ the nature of the file = e.g. not a source code file but a data file 2/ the location of the file = in site-packages as opposed to anywhere else The name resource for me is only defined by 1/ and I don't see any confusion or opposed definitions in that naming. Neither did the people that worked on this feature. But if you feel it's confusing, I am all for a separate name - I can't think of another one though, do you have one in mind ? Seems to me that ... files used by the project which must not be installed in the same place that python modules or libraries, they are called resources and resources = ... in the setup.cfg contradicts existing understanding of what a resource is in terms of Python packaging. At least I was confused. If you don't want another name, I suppose you could define the keys as actions you take against resources in setup.cfg copy_resources = doc/doc/man = destination_doc and/or move_resources = ... doc/doc/man = destination_doc And change the docs to define resource as something that indeed does live in a package, at least until it's moved by the installer, and that you can ensure they are copied or moved by using copy_resources and/or move_resources. - C ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
