Dear All,
Turns out that the assert that libtbx has no dependencies is not strictly true:
https://github.com/cctbx/cctbx_project/blob/master/libtbx/phil/tst_interface...
# XXX sorry about the cross-import here, but I really need to test this on
# something large and complex
def exercise_2 (verbose=False) :
if (not libtbx.env.has_module(name="phenix")):
print "phenix module not available: skipping advanced tests"
return
from phenix.refinement import runtime
import iotbx.phil
from time import time
phil_str = """
refinement.pdb_interpretation.secondary_structure.protein {
helix {
selection = "chain A and resseq 10:20"
}
helix {
selection = "chain A and resseq 30:40"
}
helix {
selection = "chain A and resseq 50:60"
}
}
“""
around line 190
Maybe the down tools and disentangle has more merit than appears at first glance…
Best wishes Graeme
On 22 Jan 2018, at 18:29, Dr. Robert Oeffner mailto:[email protected]> wrote:
Hi Graeme and others,
Thank you for your replies. I was not aware of all the dependencies between the various modules within the cctbx.
As I don't know much more about the cctbx than other developers I am not sure what the best course of action would be. Here are some random thoughts.
Probably never gonna happen but, ideally a code freeze for 2 or 3 weeks stopping anyone from amending or adding code to the cctbx could be spent on disentangling modules from one another and the cctbx.
I agree that there appear to be some other projects that do not belong to the cctbx. For instance, I think fable was conceived by Ralf as a one time conversion tool of F77 code to C++ code. Not sure if it is used anymore.
As for pip install ability, yes that sounds like a good idea to achieve if it is done from the lowest level first, i.e. the libtbx submodule.
Documenting how to build derived projects using the CCTBX should encourage people not to add unrelated code into the cctbx. Although SConscripts are familiar to many of us, to others SConscript or bootstrap are quite alien and opaque ways of building from sources.
cheers,
Rob
-----Original Message----- From: [email protected]mailto:[email protected]
Sent: Monday, January 22, 2018 8:58 AM
To: [email protected]mailto:[email protected]
Cc: [email protected]mailto:[email protected]
Subject: Re: [cctbxbb] Tidy up CCTBX
Hi Rob
More thinking on this one, following from a little conversation over the weekend at this end
If we were looking to be able to package cctbx in a more Pythonic manner - i.e. to allow pip install - would it make sense to start at the bottom rather than at the top? i.e. libtbx - which is pure Python with deliberately no dependencies - would be a good place to start? The lower level code is also more static so a safer candidate for pip installing compared with some of the more rapid changing things…
From a diamond perspective, there are a bunch of people here who want cctbx-without-dials-but-with-their-own-packages so being able to pip install cctbx and it's dependencies would be pretty cool…
Another happy side effect is this would allow e.g. libtbx.bootstrap to exist...
Cheers Graeme
On 19 Jan 2018, at 14:10, Winter, Graeme (DLSLtd,RAL,LSCI) mailto:[email protected]mailto:[email protected]> wrote:
Hi Rob
Interesting question. I have sympathy for your point of view. Some thoughts, from a conversation here in DIALS land…
(i) dxtbx is not only there to support DIALS - cctbx image viewer, bits of iotbx, cctbx.xfel also use it (I think)
(ii) from where I am sat this is a wider question - if I have a look in cctbx_project I see more “non core code" than just dxtbx:
Graemes-MBP-5:cctbx_project graeme$ ls
README.md cootbx fftw3tbx omptbx sphinx
boost_adaptbx crys3d gltbx prime spotfinder
cbflib_adaptbx cudatbx iota rstbx tbxx
cctbx dox iotbx scitbx ucif
chiltbx dox.sphinx libtbx simtbx wxtbx
clipper_adaptbx dxtbx mmtbx site.pyc xfel
cma_es fable msvc9.0_include smtbx
So, in here we have several things which probably do not “belong” in the world view you present below, for example fable, prime, simtbx, xfel etc.
(iii) If we are visiting this stuff, should we be visiting the wider build system which I understand is one of the “blockers” for e.g. pip install cctbx
I appreciate that this is a wider question than can we pull dxtbx out, but is essentially derived…
Best wishes Graeme
On 18 Jan 2018, at 15:56, Dr. Robert Oeffner mailto:[email protected]mailto:[email protected]> wrote:
Hi all,
I'm wondering if we could make efforts to refactor code modules in the cctbx_project so as making it have the minimum number of dependencies. This would be helpful to other users of the CCTBX that wishes to develop code on top of it. In the longer term it would also make it easier for us to deploy CCTBX as a Python wheel installer and by implication, spread the gospel of the wonders of the CCTBX.
What is currently complicating this is the inclusion of the dxtbx module within the cctbx_project. It is being used by Dials. So my question is if it would be possible to move this project into the Dials code?
If the dxtbx was just another small module it wouldn't be much of a problem. But the dxtbx depends on the cbflib and HDF5 components. If you want to build CCTBX from sources that's cumbersome. Why? Because CCTBX as deployed from CCI on http://cci.lbl.gov/cctbx_build/ is only built for a few select platforms. Building CCTBX on a different platform from those with bootstrap compels us to also build cbflib and HDF5 from scratch. Although this is not impossible it does increase the entry barrier for other potential users of the CCTBX who wish to incorporate the CCTBX in their programs: If all a user wants is to calculate allowed origins and symmetry sites for a given space group then an alternative to CCTBX might be preferable rather than having to massively expand their project with the seemingly unrelated HDF5 component. In other words, as it stands now the CCTBX is not straightforward for others to adopt.
What do other people think?
Regards,
Rob
--
Robert Oeffner, Ph.D.
Research Associate, The Read Group
Department of Haematology,
Cambridge Institute for Medical Research
University of Cambridge
Cambridge Biomedical Campus
Wellcome Trust/MRC Building
Hills Road
Cambridge CB2 0XY
www.cimr.cam.ac.uk/investigators/read/index.htmlhttp://www.cimr.cam.ac.uk/investigators/read/index.htmlhttp://www.cimr.cam.ac.uk/investigators/read/index.html
tel: +44(0)1223 763234
_______________________________________________
cctbxbb mailing list
[email protected]mailto:[email protected]mailto:[email protected]
http://phenix-online.org/mailman/listinfo/cctbxbb
--
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
_______________________________________________
cctbxbb mailing list
[email protected]mailto:[email protected]
http://phenix-online.org/mailman/listinfo/cctbxbb
---
This email has been checked for viruses by AVG.
http://www.avg.comhttp://www.avg.com/
_______________________________________________
cctbxbb mailing list
[email protected]mailto:[email protected]
http://phenix-online.org/mailman/listinfo/cctbxbb
