[Chandler-dev] Re: make distrib vs install

[bear]

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.