On Thu, Aug 18, 2011 at 10:39 AM, Ed Pozharski <span dir="ltr">&lt;<a href="mailto:epozh001@umaryland.edu">epozh001@umaryland.edu</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

In a nutshell, phenix gui may in some circumstances screw up other<br>
programs that use matplotlib.</blockquote><div><br></div><div>It&#39;s not the fault of Phenix; matplotlib is unusually inflexible in how it deals with these cache files, and it is nearly unique among Python modules in its dependence on writing to the user&#39;s home directory. �This isn&#39;t the only problem; another issue is that matplotlib creates these caches, and the maintainers appear to never have considered what would happen if the cached directory were removed. �So when you run the GUI in version X of Phenix, then remove version X and install version Y, it will still look for the fonts installed with version X. I complained about this last December, and it remains unsolved in any of the official releases (one of which was this year).�</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The likely cause is that phinix gui calls on bundled matplotlib which is<br>
different from one I have installed (not to mention that I am using<br>
Lucid (because it&#39;s LTS) which has python 2.6 and not the 2.7 that is<br>
bundled with phenix). �However, it still writes into the same<br>
~/.matplotlib folder, thus I end up with incompatible data. �Certainly,<br>
the problem will be gone when matplotlib gets bumped up to 1.0.1 in next<br>
Ubuntu release.<br></blockquote><div><br></div><div>The issue with removing installations will remain, however. �You could avoid the incompatibility problem by running &quot;phenix.wxpython&quot; if you need to use matplotlib. �(We&#39;re using Python 2.7.2 right now, and generally update to the latest release in the 2.x series shortly after it comes out.)</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
This is yet another example of why the standalone installation approach<br>
is ideologically objectionable on modern Linux. �But of course, the<br>
practical advantage gained by not having to package the software for any<br>
possible OS flavor/version users may choose outweighs the lower risks of<br>
package incompatibility and the reduced size of the packaged product.</blockquote><div><br></div><div>We don&#39;t have the resources to support a more ideologically pure distribution mechanism - the installers are maintained by me and Ralf in between other projects. �Also, we often depend on new features in the various dependencies that would not be immediately available through the package managers (for instance, we switched to Python 2.6 almost immediately because I needed the multiprocessing module). �There are many things in the current installers that I&#39;m unhappy with, but they don&#39;t take very much time to maintain, which is essential.</div>

<div><br></div><div>-Nat</div></div>