I just realized what I responded to was in the context of the recorded
script branch only.
Heikki is more accurate in that the issue goes away completely if the
new launcher is used. because it fixes the issue in a cleaner manner.
Not to say it isn't a bug on the make distrib side :)
bear wrote:
D John Anderson wrote:
On Oct 30, 2007, at 3:30 PM, Heikki Toivonen wrote:
D John Anderson wrote:
It would be nice to address the problem with the distrib target before
committing the Chandler.po fix -- otherwise there would be no way to
verify that the make distrib problem is really fixed, since the
Chandler.po fix would mask it.
I filed https://bugzilla.osafoundation.org/show_bug.cgi?id=11176 to find
out what is different with make distrib and make install and the
Chandler-en.po treatment. However, with the path issue fixed, I don't
think the Chandler-en.po treatment will be an issue anymore. So that
blocker should be gone from your point of view once you merge the trunk
to your branch.
I think there are two separate bugs here:
1) rt.py (or something it uses) doesn't set up sys.path correctly for
localization to work.
rt.py doesn't set any path or environment variables. it completely
depends on the chandler launcher it uses to do all that.
2) The fact that running Python after a "make install" results in a
sys.path that doesn't work for localization and running after a "make
distrib" results in a different, but correct sys.path for
localization. Running Python after a "make install" or "make distrib"
should not affect Python's sys.path for localization, right?
the issue seems to be, and this is from me just doing a quick look at
the dir/file diffs between a make install and a make distrib, that the
.po files are not in the *exact* place between the two.
why I don't know - they are installed as egg_info resource files, so I
need to track down (and double check with pje) as to why they would be
located in two locations when one is in develop mode and the other is not.
Committing the fix for bug 1 will mask bug 2, on the tinderboxes but
this doesn't mean that bug 2 is fixed. For example, running from Wing
after a make install will still result in the incorrect localization,
which makes it important to get fixed.
yes, it will mask it but I can use a previous revision to test against.
what I want is for you to get unblocked and if this does that at the
risk of me having a little bit more involved verify process then it's a
no-brainer... you should be unblocked.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
