"it's just a reader" - basically read particles to be stored in imp - can be writtern in python,c++ does not matter much - it only initializes imp particles. But, we should think weather we need a molecule_utils lib ( like superpose, selection, surface generator ...) - I guess we do, and then the question is should we use some c++ lib for that or write it ourselfs ( we certainly should not use python lib for that ... :) )
As for just a pdb reader, since it only reads atoms and put then in IMP we can have in the meantime even a few readers and converge to something as time passes. I would recommend that we have a few test cases that check main functionalities ( multiple positions, HETATMs, chains, symmetry ..... ) - so that we can have some objective criteria for a final decision. I can also offer considering c++ code written in my lab in TA which was used for structural alignment and docking procedures - so it was debugged well.
On Nov 14, 2007, at 6:53 PM, Daniel Russel wrote:
> I think Ben and I have a disagreement about the significance of > picking a PDB reader at this point. As I see it, any PDB reading > should be hidden behind some very general interface (I have a > proposal using the MolecularHierarchyDecorator). As a result, the > code doing the actually reading doesn't matter too much and so we > shouldn't worry now about whether we have the perfect solution. We > should pick something easy which does what we want and minimizes the > amount of effort people have to make.
> > When someone needs something more, we can either modify our current > solution or chuck it and write an adaptor to someone else's code. > Writing these adaptors is trivial given a backend which supports all > we want. > > I picked my pdb reader since it is small and so can be stuck in the > with rest of imp so that no one has to worry about installing > external libraries and it does what I want, namely give me a > hierarchy for proteins and a bond information. > > The alternatives I have looked at so far are > > BALL- probably dead although it took a breath this morning > > the one Frido sent- I don't see how to get bonds out of it, but > otherwise fine. The documentation really sucks, so I might be missing > something. > > a few random other C and C++ ones all of which are either embedded in > a large library, suck, don't give me bonds etc. > > One area I haven't looked is the in python only readers. There may be > some good ones there. > >> >> If it's an external library, it should be a dependency, not part of >> IMP. > It depends. Having obscure external dependencies is a good way to > piss off people who have to install your software. It is a tradeoff. > I would say that we shouldn't depend on anything not in fedora or > fedora-extras for something basic like this. >> > >> Hao's project absolutely requires HETATMs, for example. And I >> don't share your concern for runtime checks, since PDB reading is not >> performance-critical. > My concern on checks was not for efficiency, it was for correctness. > Depending on strings is poor as capitalization or abbreviation errors > don't easily get caught. > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev