[gmx-developers] Python package build

[Eric Irrgang]

Hi Alexey,

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.)

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.

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).

> without calling pip and other 3rd party package managers

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, gromacs.org, and
the user)

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.

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.

On Fri, Jan 17, 2020 at 1:12 AM Alexey Shvetsov <alexxy at omrb.pnpi.spb.ru>
wrote:

> Hi!
>
> To my mind its better to have pyapi installed as a part of gromacs package
> using CMake build system (without calling pip and other 3rd party package
> managers). It will simplyfy usage of pyapi and packaging it for
> distribution.
>
>
> В письме от четверг, 16 января 2020 г. 21:12:51 MSK пользователь Eric
> Irrgang
> написал:
> > Hi Devs,
> >
> > In the teleconference yesterday, I asked you to think about issue
> > https://redmine.gromacs.org/issues/2896
> >
> > 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.
> >
> > 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.
> >
> > The issue description at https://redmine.gromacs.org/issues/2896 should
> be
> > substantially rewritten if we decide to change course. Please review the
> > latest comment(s) and contribute your thoughts.
> >
> > In summary:
> >
> > # Reasons to turn gmxapi Python package build into a main GROMACS build
> > system entry point
> >
> > * Make it easier to achieve a Python package build environment compatible
> > with the GROMACS library build environment.
> > * 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.
> > * Simplify Python package installation, testing, maintenance and
> packaging
> > (as for PyPI)
> > * Possibly, facilitate the beginning of a smooth transition towards
> > internal integration of gmxapi with tools and tests.
> >
> > # Reasons to keep gmxapi Python package as a client of the public C++
> > interface
> >
> > * Decouple Python package version from GROMACS release.
> > * Decouple the Python package requirements from the requirements of the
> > main build system participants.
> > * Much shorter build time for Python package.
> > * Much reduced Python distribution package size.
> > * Python package provides a ready client of the GROMACS public C++ API to
> > facilitate "dog-fooding" and integration testing.
> > * Let sysadmins worry about building an efficient libgromacs, and let
> users
> > just to `pip install gmxapi`. (unfortunately, it's not quite that easy)
> > * Avoid Python packaging boiler plate in the root directory of the
> > repository.
> >
> > Best,
> > Eric
>
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20200120/225d92f3/attachment.html>