<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Devs,<br><div><br></div><div>In the teleconference yesterday, I asked you to think about issue <a href="https://redmine.gromacs.org/issues/2896">https://redmine.gromacs.org/issues/2896</a></div><div><br></div><div>Specifically, I am asking you to weigh in on whether the gmxapi Python package should continue to be a client package of a GROMACS installation, or whether it should _be_ a GROMACS installation.</div><div><br></div><div>The decision has significant impact on priorities for installed headers / public API, and build system infrastructure. Furthermore, details of such a reorganization could take a while to reach consensus. For these reasons, I think we should affirm a course as early as possible.</div><div><br></div><div>The issue description at <a href="https://redmine.gromacs.org/issues/2896">https://redmine.gromacs.org/issues/2896</a> should be substantially rewritten if we decide to change course. Please review the latest comment(s) and contribute your thoughts.</div><div><br></div><div>In summary:<br></div><div><br></div><div># Reasons to turn gmxapi Python package build into a main GROMACS build system entry point</div><div><br></div><div>* Make it easier to achieve a Python package build environment compatible with the GROMACS library build environment.</div><div>* Allow Python package to be implemented without reliance on installed headers or libgmxapi.so, allowing more flexibility in how we handle changes to the public C++ API later in the year.</div><div>* Simplify Python package installation, testing, maintenance and packaging (as for PyPI)</div><div>* Possibly, facilitate the beginning of a smooth transition towards internal integration of gmxapi with tools and tests.</div><div><br></div><div># Reasons to keep gmxapi Python package as a client of the public C++ interface</div><div><br></div><div>* Decouple Python package version from GROMACS release.<br></div><div>* Decouple the Python package requirements from the requirements of the main build system participants.</div><div>* Much shorter build time for Python package.</div><div>* Much reduced Python distribution package size.</div><div>* Python package provides a ready client of the GROMACS public C++ API to facilitate &quot;dog-fooding&quot; and integration testing.</div><div>* Let sysadmins worry about building an efficient libgromacs, and let users just to `pip install gmxapi`. (unfortunately, it&#39;s not quite that easy)</div><div>* Avoid Python packaging boiler plate in the root directory of the repository.</div><div><br></div><div>Best,</div><div>Eric</div><div></div></div></div></div></div></div></div>