[Chandler-dev] Re: EggResourceManager ready for review

Phillip J. Eby pje at telecommunity.com
Fri Jul 28 17:26:08 PDT 2006

At 01:43 PM 7/28/2006 -1000, Brian Kirsch wrote:
>Thanks for the suggestion,
>The new and improved tar ball is attached to this mail.

Much better, thanks.  It's a lot easier to see what's going on now.

Three minor remaining issues regarding packaging:

1. It appears that your 'tests/' directory isn't under revision control; it 
didn't get picked up in this tarball.

2. It might be best to relocate the test resources to an unpacked egg 
project inside of the tests/ directory; in this way, the test resources 
won't have to be installed with the runtime, but would be shipped with the 
source version of the package.

This change is harder to explain than to do so it can wait until this has a 
home in OSAF SVN and I can just do it; it will be easier to see what I mean 
after I've done it, than to try to explain it in advance.  But basically it 
will be just creating a second .egg-info directory used only for the tests 
and not for the distribution.

3. It appears that you have some test directories with UTF-8(?) encoded 
characters in them; it's not clear to me whether these will work properly 
on platforms that don't use UTF-8 or Latin-1 encoding.  However, if I do 
the move described in #2 the files will only ship for source distributions, 
not binary installs, so it may not be worth bothering with.

However, if the intent of your tests is to claim that resource paths can be 
non-ASCII, I do want to remind you that pkg_resources does not claim to 
support anything but ASCII for resource and metadata paths, since they may 
be on the filesystem directly *or* embedded in a zipfile, and I'm not aware 
of what encoding support (if any) is provided for zipfiles, especially the 
libraries that I use to pack and unpack .egg files.  So, your tests may be 
relying on unsupported behavior here.

Anyway, that's it for packaging-related issues, I will go look at the 
actual code itself next.  :)

With regard to the name, I suggest that a simple name like 
"EggTranslations" might be the best choice from a marketing 
perspective.  Libraries that are looking to become a defacto standard for 
the language are usually better off having names that suggest they are the 
"One Obvious Way" to do something, not to mention it being more obvious to 
people what they might use the package for.  :)

More information about the chandler-dev mailing list