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>