[gmx-developers] Python package build

[Benson Muite]

Am not a core developer, but comments below

On 1/20/20 1:55 PM, Eric Irrgang wrote:
> 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 <http://gromacs.org>, and the user)
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.
>
> 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 <mailto: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
>     <mailto: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/ced9e9cf/attachment-0001.html>