On 4/20/06, "Martin v. Löwis" firstname.lastname@example.org wrote:
- "package resources". I dislike the term resources (it is not about natural gas, water, main memory, or processor cycles, right?); instead, this seems to provide access to "embedded" data files. Apparently, there is a need for it, so be it. -0
The "resources" name is actually quite a common meme; e.g. the Google internal API for this is in a module named "resources.py" (Google has its own set of functionality not unlike eggs).
I'm also surprised you're -0 on the functionality. Lots of code has associated data files that must be distributed together with it, and IMO this is an absolutely essential feature for any packaging and distribution tool. 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.
- I disliked the fact that nobody explicitly approved inclusion of setuptools. Now that Anthony Baxter did, I'm fine.
That's my fault. I told Phillip in no unclear terms that I wanted it. That was enough of an approval for me (and for Neal and Anthony, who were aware AFAIK). But I forgot to clarify this to python-dev. (Like with the proposal to turn print into a function, I assumed it was obvious that it was a good idea. :-)
- I still fear that the code of setuptools will turn out to be a maintenance nightmare.
AFAICT Phillip has explicitly promised he will maintain it (or if he doesn't, I expect that he would gladly do so if you asked). This has always been sufficient as a "guarantee" that a new module isn't orphaned. Beyond that, this objection is FUD; the circumstances of the original distutils aren't likely to be replicated here.
-- --Guido van Rossum (home page: http://www.python.org/%7Eguido/)