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. :)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
