<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Thank you for the thorough comments. Some clarifications inline below.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 21, 2020 at 1:59 PM Stian Soiland-Reyes &lt;<a href="mailto:soiland-reyes@cs.manchester.ac.uk" target="_blank">soiland-reyes@cs.manchester.ac.uk</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">First case avoid Gromacs ABI mismatch as you point out, but is then more<br>
sensitive to Python&#39;s ABIs, e.g. you update your Python from 3.7 to 3.8<br>
and you might need a whole new Gromacs compile. <br></blockquote><div><br></div><div>They are equally sensitive to Python version, but the cost to rebuild is different.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">It is also possible to avoid this by<br>
sticking to &lt;<a href="https://docs.python.org/3/c-api/stable.html" rel="noreferrer" target="_blank">https://docs.python.org/3/c-api/stable.html</a>&gt;<br></blockquote><div><br></div><div>This does not provide ABI stability, and recompilation is still required. Python ABI stability is improving, but I don&#39;t think we can ever count on a single module build for all Python installations.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">IMHO think first option is preferable if the Python API is co-evolving<br>
with the C++ API.<br>
<br>
However this means Python users are not able to depend on an older<br>
Python API with a newer Gromacs - they are stuck to whatever Python API<br>
comes with their chosen Gromacs.<br></blockquote><div><br></div><div>Python API stability is a goal in any case, but we aren&#39;t there yet. In practice, we are not currently attempting to support multiple GROMACS releases for gmxapi 0.x versions, and this build system question does not affect that.</div><div><br></div><div>As the Python API stabilizes, we can start to provide a compatibility guarantee by updating the Python package implementation in terms of the evolving GROMACS. New versions of GROMACS will require Python package updates until there is a sufficient and stable GROMACS C++ API (if ever). There is currently no expectation of a stable GROMACS ABI.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">When the Python-side API is stable this is less of an issue - but it<br>
means it&#39;s harder to have separate semantic versioning for the Python<br>
API.<br></blockquote><div><br></div><div>This is an open question, but somewhat divorced from the present issue, since the GROMACS repository is where the Python package sources live for all packaging scenarios.</div><div><br></div><div><div style="color:rgb(0,0,0)">In other words:</div><div style="color:rgb(0,0,0)">* We won&#39;t tag gmxapi 1.0 until we are sure that Python scripts written for it will also run on future gmxapi 1.x.</div><div style="color:rgb(0,0,0)">* To use a new version of GROMACS the Python bindings package will need to be updated for the foreseeable future, and the Python package will likely always need to be recompiled.</div><div style="color:rgb(0,0,0)">* It is unclear whether/when we will try to support older versions of GROMACS in updated Python packages, but it is clear that this is not a priority for the current development cycle.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Having &quot;pip install&quot; do the compilation of the binding on install is<br>
possible (scikit-build), although slightly awkward as the client may<br>
need to have the right compiler paths etc, not to mention find the right<br>
gromacs install and headers. If they have installed Gromacs from a<br>
binary package (Conda, Debian, modules), then this may not be straight<br>
forward, although GMXRC helps.  &lt;<a href="https://scikit-build.readthedocs.io/" rel="noreferrer" target="_blank">https://scikit-build.readthedocs.io/</a>&gt;<br></blockquote><div><br></div><div>This is the situation we are in right now, and the reason I raised the question.</div><div>Refs:</div><div>* <a href="https://redmine.gromacs.org/projects/gromacs/repository/revisions/master/entry/python_packaging/src/setup.py" target="_blank">https://redmine.gromacs.org/projects/gromacs/repository/revisions/master/entry/python_packaging/src/setup.py</a></div><div>* <a href="https://redmine.gromacs.org/projects/gromacs/repository/revisions/master/entry/python_packaging/src/CMakeLists.txt" target="_blank">https://redmine.gromacs.org/projects/gromacs/repository/revisions/master/entry/python_packaging/src/CMakeLists.txt</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Again this would be sensitive to updates - would the pip-version need to<br>
match the gromacs version or would the older Python code seemlessly work<br>
if Gromacs got updated later, or if for some reason they wanted to<br>
compare Gromacs 2019 and 2020 using the same Python calls?<br></blockquote><div><br></div><div>The long-term plan is that the pip-installed version will be tied to a specific GROMACS installation, and different GROMACS versions would be comparable through separate virtual environments in which gmxapi uses different GROMACS installations. Under the proposed change, these GROMACS installations would be self-contained within the Python package installation instead of managed separately.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">As Eric point out this means the gmxapi would be more restricted in its<br>
changes - as the Python lib is installed separately it is not priviliged<br>
compared to other API users - &quot;eat our own dogfood&quot; could flag up<br>
any unintentional API/ABI changes.<br></blockquote><div><br></div><div>Exactly. And I think this is still a plausible long-term goal. I don&#39;t know whether it is worth trying to maintain at this stage, though.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Alternatively you can include the prebuilt shared library in the<br>
published wheel package, which you would then need to build for multiple<br>
architectures and OSes - you are then sensitive to the installation path<br>
say in virtualenv (RPath magic to the rescue?).<br>
</blockquote><div><br></div><div>There has been talk for the last few development cycles about making such updates to libgromacs, but I don&#39;t think it is on a concrete roadmap or likely to happen any time soon. But there&#39;s really no need to use a separate shared library in this case, since the idea would be to use the CMake infrastructure to give us a static target build with position-independent code that we can link into the Python bindings module shared object.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I doubt this is right for Gromacs given the diverse hardware usage base.<br>
&lt;<a href="https://packaging.python.org/guides/packaging-binary-extensions/" rel="noreferrer" target="_blank">https://packaging.python.org/guides/packaging-binary-extensions/</a>&gt;<br></blockquote><div><br></div><div>Again, I am skeptical that it will ever be feasible to distribute the Python package as a precompiled binary or that there would be a compelling reason to do so.</div><div><br></div><div>Thank you again for your comments. I think this has been a good review of the considerations and state of development.</div><div><br></div><div>Best,</div><div>Eric</div></div></div></div></div></div></div>