Hi PJE,
See comments in-line.
Phillip J. Eby wrote:
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.
Not following when you say revision control. None of the code as of yet
is under revision control ala SVN.
Since tests did not get included in the sdist egg I assume I need to add
some additional
entry to setup.py. But I am sure you can tell me what step is needed or
missing.
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.
Yes, I totally get what you are saying and agree that this would be a
better solution so that the resources used for testing are not bundled
with the distributed egg.
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.
I have tests of file encodings, pathing, and resource.ini files that are
in UTF-8. I also have tests
for loading resource files and a resource.ini file in the shift-jis
encoding.
It is true that Python is supported on many additional platforms beyond
what Chandler requires (OS X, Linux Ubuntu, Windows XP).
For those platforms that do support these encodings it does not matter
cause as you said the tests are not shipped with the
dist egg.
However, I want these charset encoding tests there for Chandler and
other Python projects on Linux, OS X,
and Windows XP to assure that the library has the best encoding support
possible.
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.
Yes, that is a concern. Again, I wanted to make sure the
EggResourceManager had the best encoding and pathing support possible. I
will need to look further in to the zip format to see if non-ascii
pathing is supported.
But it would surprise me if the zip format was not able to compress
directory structures that contained a non-ascii character.
In fact, I just zipped and unzipped successfully a directory structure
that did contain non-ASCII paths.
However, requiring only ASCII file paths in the egg is fine. I think
anything beyond that is merely a nice to have
feature and not a must have feature.
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. :)
Yes I think this is a great suggestion. I was always considering the
name EggResourceManager to be a temporary place holder.
I would like to talk to you further about marketing and other aspects of
releasing a library to the community.
I know you have had much experience with setuptools and other projects
you have worked on in this regard.
I really do feel that with a little refinement the 'EggTranslations' can
be the defacto standard for localizing in Python.
If you could please send me you comments on the actual API and code when
you get a chance I would appreciate it
as I am in the process of integrating the current work with Chandler.
Thanks,
Brian
--
Brian Kirsch
Internationalization Architect/ Mail Service Engineer
Open Source Applications Foundation
543 Howard Street 5th Floor
San Francisco, CA 94105
http://www.osafoundation.org
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
