<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Am not a core developer, but comments below<br>
</p>
<div class="moz-cite-prefix">On 1/20/20 1:55 PM, Eric Irrgang wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CANMuMvkVm5zMbbF2P4AoF=Gjwirg2WnTta=_4w_MXkV5iWa2eQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">gromacs.org</a>, and the user)</div>
</div>
</div>
</blockquote>
Packaging is probably important. In many beginner tutorials, "sudo
apt-get install gromacs" is commonly used to avoid compilation
issues. That being said, it would be helpful if developers could
completely turn off python and still have a usable installation
solely in a relatively low level language so that adding new
features and testing on new hardware is possible. Ensuring
compatibility between Python packaging and Linux distribution
packaging can be a pain. One might consider having a Python version
on Pypi so that beginners still have an easy way to install. App
images (or other similar portable instalable linux versions) are
another possible alternative to avoid beginners needing to compile.<br>
<blockquote type="cite"
cite="mid:CANMuMvkVm5zMbbF2P4AoF=Gjwirg2WnTta=_4w_MXkV5iWa2eQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<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"
moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">gmx-developers-request@gromacs.org</a>.</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
</body>
</html>