[cctbxbb] cctbx.python unnecessarily unfriendly

Thu Jan 9 00:06:17 PST 2014

Hi All,

On the distutils thing: I agree completely with Nat that in terms of developing cctbx it would be a monumental pain to have to be running python setup install all the while... however for someone who wants to *use* cctbx in the same way as they use matplotlib and so on (there are a lot of people like this here at Diamond - physical scientists mostly) it would be a great help to be able to install cctbx in the way that they are used to.

So what would be really cool would be to be able to use distutils methods to *install* cctbx in the usual pythonic way, but to keep up with the current mechanism for *working on* cctbx - though the Scons build mechanism may not help this... Could it be possible to run the two side-by-side? I have encountered people for whom this is a blocker for example they want to just add cctbx to their enthought python installation or something...

(agreed though about the Phenix caveats: this is not useful for Phenix and for the large part that is where the $$ come from for cctbx so ...)

I'll ask around here to see if anyone is interested in looking into this...

Thanks & cheerio, Graeme

From: cctbxbb-bounces at phenix-online.org [mailto:cctbxbb-bounces at phenix-online.org] On Behalf Of Nathaniel Echols
Sent: 09 January 2014 01:21
To: cctbx mailing list
Subject: Re: [cctbxbb] cctbx.python unnecessarily unfriendly

On Wed, Jan 8, 2014 at 5:05 PM, Luc Bourhis <luc_j_bourhis at mac.com<mailto:luc_j_bourhis at mac.com>> wrote:
The dispatcher's main job is to set PYTHONPATH, DYLD_LIBRARY_PATH on MacOS X, LD_LIBRARY_PATH on Linux and PATH on Windows, as well as LIBTBX_BUILD. Thus it can be argued that it is a by-product of the way the cctbx installs itself on a system.

Actually, a major justification for the dispatchers was to avoid the "pollution" of the environment in ways that might interfere with other packages.  (This is why the default behavior is also to completely wipe any existing values of LD_LIBRARY_PATH, etc.)  Again, this mainly makes deployment of Phenix easier.

By that I mean that if we installed it with distutils like your typical Python package, then /usr/bin/python would be able to run any cctbx-based script because the cctbx shared libraries and Python modules would be where /usr/bin/python could find them, and we would just need to decide on where to put libtbx_env inside site_packages.

The reason why we don't do this is simply to speed development - there's no distinction between the working code (i.e. SVN checkout) and runtime code.  Otherwise we might have to run "python setup.py install" every time we want to test even the most minor change.  There are almost certainly other ways to avoid this requirement, but that was the logic at the time.

For historical reasons, this is not the path that was taken. It can certainly be rectified but as Nat said, Phenix takes precedence here, since the cctbx effort ultimately relies on the funding of Phenix. As long as the Phenix people aren't comfortable with removing -Qnew or with making the installation rely on distutils, then so be it.

It's not a matter of comfort: the limitation is what we have time for (or money, which is basically the same thing).  Removing -Qnew is probably easy enough to be justified if it makes CCTBX as a whole more usable.  I don't think anyone would argue against converting to use distutils on technical grounds; we're simply too busy.  I can't speak for the other developers, but if someone else outside our group were willing to do this we would probably not complain and might even encourage it, as long as it didn't interrupt our day jobs.

-Nat

-- 

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.

Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 

Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.

Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phenix-online.org/pipermail/cctbxbb/attachments/20140109/6bd0381c/attachment.htm>