Thanks to some superb work by Nader Morshed, Oliver Zeldin, and Ian Rees, we now have automatically updated Sphinx docs for CCTBX: http://cci.lbl.gov/cctbx_docs/ Obviously these are still pretty sparse - right now most of the formal documentation is clustered here: libtbx libtbx.utils libtbx.phil (mostly re-using Ralf's old documentation) cctbx.miller iotbx.pdb (built on Ralf's newsletter article) mmtbx.command_line These are a combination of inline docstrings and separate restructured text files in cctbx_project/sphinx. We have automatically generated rst files for some modules, but others will need to be added manually. In the end I think we'll want to curate every file, but the current layout will get us started. To facilitate additional contributions, I've modifed the installation script for base packages to include a --sphinx option. After setting up CCTBX you can then do this: cd $BUILD libtbx.configure sphinx cd $SRC/cctbx_project/sphinx make html and you will get the full documentation built locally. I am still figuring out how to use Sphinx effectively; it is definitely possible to document Boost.Python extensions but it's not quite as obvious. I don't expect us to retroactively document several hundred thousand lines of code written over a decade, but if we can get the core parts thoroughly covered that will greatly reduce the barrier for new developers. Suggestions for particular modules to focus on are appreciated; I am going to try to cover the basic PDB+reflection file functionality. I encourage anyone doing CCTBX-related development to contribute as you go. (They don't need to be your own APIs, just modules you're reasonably familiar with.) Those of you who already have a ton of undocumented code can expect me to harass you periodically about fixing this. (Note that I've cannibalized at least one newsletter article for this, and continue to do so; we should re-use existing prose descriptions as much as possible without violating copyrights.) -Nat
Thanks a lot Nat, Nader, Oliver and Ian, that looks like a good start and
hopefully it will motivate more of us to gradually contribute bits of
documentation here and there.
I had a go at starting to document cctbx.uctbx.unit_cell, which as you know
is mainly a Boost.Python extension (
https://sourceforge.net/p/cctbx/code/20467/). Before I travel too much
further down this route, is this an appropriate way of documenting
Boost.Python extensions or is there a better way we can do this?
It would be good to get the documentation for the core cctbx classes up and
running, however several of the core classes (e.g. cctbx.sgtbx.space_group,
cctbx.uctbx.unit_cell, flex arrays) are mostly Boost.Python extensions, so
it would be good to arrive at a sensible way to document these extensions.
Cheers,
Richard
On 13 August 2014 16:13, Nathaniel Echols
Thanks to some superb work by Nader Morshed, Oliver Zeldin, and Ian Rees, we now have automatically updated Sphinx docs for CCTBX:
http://cci.lbl.gov/cctbx_docs/
Obviously these are still pretty sparse - right now most of the formal documentation is clustered here:
libtbx libtbx.utils libtbx.phil (mostly re-using Ralf's old documentation) cctbx.miller iotbx.pdb (built on Ralf's newsletter article) mmtbx.command_line
These are a combination of inline docstrings and separate restructured text files in cctbx_project/sphinx. We have automatically generated rst files for some modules, but others will need to be added manually. In the end I think we'll want to curate every file, but the current layout will get us started. To facilitate additional contributions, I've modifed the installation script for base packages to include a --sphinx option. After setting up CCTBX you can then do this:
cd $BUILD libtbx.configure sphinx cd $SRC/cctbx_project/sphinx make html
and you will get the full documentation built locally. I am still figuring out how to use Sphinx effectively; it is definitely possible to document Boost.Python extensions but it's not quite as obvious.
I don't expect us to retroactively document several hundred thousand lines of code written over a decade, but if we can get the core parts thoroughly covered that will greatly reduce the barrier for new developers. Suggestions for particular modules to focus on are appreciated; I am going to try to cover the basic PDB+reflection file functionality. I encourage anyone doing CCTBX-related development to contribute as you go. (They don't need to be your own APIs, just modules you're reasonably familiar with.) Those of you who already have a ton of undocumented code can expect me to harass you periodically about fixing this.
(Note that I've cannibalized at least one newsletter article for this, and continue to do so; we should re-use existing prose descriptions as much as possible without violating copyrights.)
-Nat
_______________________________________________ cctbxbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/cctbxbb
On Fri, Aug 15, 2014 at 8:06 AM, Richard Gildea
I had a go at starting to document cctbx.uctbx.unit_cell, which as you know is mainly a Boost.Python extension ( https://sourceforge.net/p/cctbx/code/20467/). Before I travel too much further down this route, is this an appropriate way of documenting Boost.Python extensions or is there a better way we can do this?
I haven't had enough time to experiment to decide on the best approach. I see three choices - the first is what you've done: class my_class (ext.my_class) : """doc""" def boosted_function (self, some_argument) : """function doc""" super(ext.my_class, self).boosted_function(some_argument) OR (2): ext.my_class.__doc__ = """doc""" ext.my_class.boosted_function.__func__.__doc__ = """function doc""" OR (3): put the docstrings in C++ code, for instance: .def("boosted_function", &my_class::boosted_function, "function doc") (not sure what the equivalent is for classes but it's probably pretty similar) My opinion is that (1) is much too prone to confusion and API conflicts unless we're already using this code structure (and FYI, you broke the call signatures for a couple of methods). (3) is just gross. (2) is also gross but has the virtue of being the least likely to break, and doesn't require modifying C++ files. So I'm inclined to take that approach (For what it's worth, when modifying a class using the boost.python injector, we appear to be able to set __doc__ inside there; see iotbx.pdb.hierarchy for an example.) It would be good to get the documentation for the core cctbx classes up and
running, however several of the core classes (e.g. cctbx.sgtbx.space_group, cctbx.uctbx.unit_cell, flex arrays) are mostly Boost.Python extensions, so it would be good to arrive at a sensible way to document these extensions.
Agreed. I think for flex arrays we will be stuck writing the docstrings in C++ - however since these are relatively stable APIs it should be reasonably straightforward. -Nat
Hi guys, my 2p about that if you don't mind. I think that ideally, we should try to find a way to pass the doxygen documentation into Sphinx. If it is too much work to figure out, then of your 3 variants, (3) would be my preferred choice because it puts the documentation as close to the code that is actually documented, i.e. the wrapped C++ code. If the code has already been structured as your (1), this is most likely because the Python function does more than the C++ function, and the documentation should be in the overriden Python function then. Your variant (2) is just too ugly to my taste. Best wishes, Luc
this:
https://github.com/michaeljones/breathe/tree/master
Is referenced in the sphinx FAQ, and seems pretty stable. Thoughts?
Oli
On Fri, Aug 15, 2014 at 9:56 AM, Luc Bourhis
Hi guys,
my 2p about that if you don't mind.
I think that ideally, we should try to find a way to pass the doxygen documentation into Sphinx.
If it is too much work to figure out, then of your 3 variants, (3) would be my preferred choice because it puts the documentation as close to the code that is actually documented, i.e. the wrapped C++ code. If the code has already been structured as your (1), this is most likely because the Python function does more than the C++ function, and the documentation should be in the overriden Python function then. Your variant (2) is just too ugly to my taste.
Best wishes,
Luc
_______________________________________________ cctbxbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/cctbxbb
-- Dr. Oliver B. Zeldin Brunger Group Stanford University
Would the sphinx docs generated via doxygen be exactly what we would want
for the Python interface? Would they be able to differentiate which parts
of the C++ interface are exposed to Python and which are not? It isn't
clear to me that documentation of the C++ interface is necessarily the same
as documentation of the Python interface. To a user of the Python
interface, it should ideally be transparent as to whether a given
class/function is a pure Python implementation or a Boost.Python extension.
Of Nat's suggestions I prefer number 2 as the simplest. I don't like the
idea of having to write the documentation into the Boost.Python binding.
On 15 August 2014 18:12, Oliver Zeldin
this:
https://github.com/michaeljones/breathe/tree/master
Is referenced in the sphinx FAQ, and seems pretty stable. Thoughts?
Oli
On Fri, Aug 15, 2014 at 9:56 AM, Luc Bourhis
wrote: Hi guys,
my 2p about that if you don't mind.
I think that ideally, we should try to find a way to pass the doxygen documentation into Sphinx.
If it is too much work to figure out, then of your 3 variants, (3) would be my preferred choice because it puts the documentation as close to the code that is actually documented, i.e. the wrapped C++ code. If the code has already been structured as your (1), this is most likely because the Python function does more than the C++ function, and the documentation should be in the overriden Python function then. Your variant (2) is just too ugly to my taste.
Best wishes,
Luc
_______________________________________________ cctbxbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/cctbxbb
-- Dr. Oliver B. Zeldin Brunger Group Stanford University
_______________________________________________ cctbxbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/cctbxbb
participants (4)
-
Luc Bourhis
-
Nathaniel Echols
-
Oliver Zeldin
-
Richard Gildea