<div dir="ltr"><div dir="ltr">Hi Alexey,<br><div><br></div><div>I think you are voting for deeper integration of the Python package with the GROMACS build infrastructure. (More specifically, you are voting for an installation use case that warrants tighter integration of the Python package and library build.)</div><div><br></div><div>We can revisit discussion about how and where the package is installed, but I want to separate the fundamental design constraints from the use cases targeted. The issue description will need to be updated with respect to installation use cases if we decide to couple the Python package to the build tree instead of to the installed C++ API.</div><div><br></div><div>In either case, I can also update the issue at a later point to discuss compliance with Python packaging and metadata conventions (ref PEP 345, 517, 518, and others).</div><div><br></div><div>> without calling pip and other 3rd party package managers</div><div><br></div><div>I have avoided taking on the overhead of supporting managers like Conda or Debian (I think that would make for at least 4 parties... ;-) ), since the Python package metadata and structure conventions are effective for simplifying installation, uninstallation, dependency resolution, and compatibility checking. (3 parties? Python environment, <a href="http://gromacs.org" target="_blank">gromacs.org</a>, and the user)</div><div><br></div><div>Regarding `pip`: the native Python `setuptools` module is the easiest way I have found to generate the metadata and package structure, and `pip` has been the easiest front-end to document. scikit-build has been the easiest way to configure a CMake build system for an arbitrary Python environment, and its primary use case is to extend setuptools.</div><div><br></div><div>We can talk about the merits and costs of breaking the dependency on setuptools and scikit-build, but I think that is beyond the scope of the immediate discussion. The ABI improvements in Python >= 3.7 may ultimately allow us to build a package just once on a system, but that is a subject for next year.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 17, 2020 at 1:12 AM Alexey Shvetsov <<a href="mailto:alexxy@omrb.pnpi.spb.ru" target="_blank">alexxy@omrb.pnpi.spb.ru</a>> 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">Hi!<br>
<br>
To my mind its better to have pyapi installed as a part of gromacs package <br>
using CMake build system (without calling pip and other 3rd party package <br>
managers). It will simplyfy usage of pyapi and packaging it for distribution.<br>
<br>
<br>
В письме от четверг, 16 января 2020 г. 21:12:51 MSK пользователь Eric Irrgang <br>
написал:<br>
> Hi Devs,<br>
> <br>
> In the teleconference yesterday, I asked you to think about issue<br>
> <a href="https://redmine.gromacs.org/issues/2896" rel="noreferrer" target="_blank">https://redmine.gromacs.org/issues/2896</a><br>
> <br>
> Specifically, I am asking you to weigh in on whether the gmxapi Python<br>
> package should continue to be a client package of a GROMACS installation,<br>
> or whether it should _be_ a GROMACS installation.<br>
> <br>
> The decision has significant impact on priorities for installed headers /<br>
> public API, and build system infrastructure. Furthermore, details of such a<br>
> reorganization could take a while to reach consensus. For these reasons, I<br>
> think we should affirm a course as early as possible.<br>
> <br>
> The issue description at <a href="https://redmine.gromacs.org/issues/2896" rel="noreferrer" target="_blank">https://redmine.gromacs.org/issues/2896</a> should be<br>
> substantially rewritten if we decide to change course. Please review the<br>
> latest comment(s) and contribute your thoughts.<br>
> <br>
> In summary:<br>
> <br>
> # Reasons to turn gmxapi Python package build into a main GROMACS build<br>
> system entry point<br>
> <br>
> * Make it easier to achieve a Python package build environment compatible<br>
> with the GROMACS library build environment.<br>
> * Allow Python package to be implemented without reliance on installed<br>
> headers or libgmxapi.so, allowing more flexibility in how we handle changes<br>
> to the public C++ API later in the year.<br>
> * Simplify Python package installation, testing, maintenance and packaging<br>
> (as for PyPI)<br>
> * Possibly, facilitate the beginning of a smooth transition towards<br>
> internal integration of gmxapi with tools and tests.<br>
> <br>
> # Reasons to keep gmxapi Python package as a client of the public C++<br>
> interface<br>
> <br>
> * Decouple Python package version from GROMACS release.<br>
> * Decouple the Python package requirements from the requirements of the<br>
> main build system participants.<br>
> * Much shorter build time for Python package.<br>
> * Much reduced Python distribution package size.<br>
> * Python package provides a ready client of the GROMACS public C++ API to<br>
> facilitate "dog-fooding" and integration testing.<br>
> * Let sysadmins worry about building an efficient libgromacs, and let users<br>
> just to `pip install gmxapi`. (unfortunately, it's not quite that easy)<br>
> * Avoid Python packaging boiler plate in the root directory of the<br>
> repository.<br>
> <br>
> Best,<br>
> Eric<br>
<br>
-- <br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.</blockquote></div>