Python vs C

[rhc54]

I'm starting work on a new "elastic" HPC scheduler and am trying to decide on the language to use. I'm equally happy to write it in Python or C. Setting aside the pros/cons of the two languages, my question here regards the packaging of the end result - my sponsor very much wants to see this project contributed to OpenHPC when appropriate.

You have a couple of my C-based packages already in your distribution, so I know there is no problem integrating packages based on that language. One of those packages (PMIx) has Python bindings, but I note that these have never been enabled or distributed here - I'm not sure why (lack of interest, integration obstacles, ...).

My question therefore is: are C-based packages easier to absorb and distribute? Is there some special "sauce" I should use if I want to go the Python route that would make it easier for you to distribute it? Could you perhaps point me to an example or two of a Python package that is already included and might serve as a guide for my work?

Thanks in advance
Ralph

[adrianreber]

You have a couple of my C-based packages already in your distribution, so I know there is no problem integrating packages based on that language. One of those packages (PMIx) has Python bindings, but I note that these have never been enabled or distributed here - I'm not sure why (lack of interest, integration obstacles, ...).

Not completely sure about the history here, but I would assume lack of interest. No one was asking for it.

My question therefore is: are C-based packages easier to absorb and distribute? Is there some special "sauce" I should use if I want to go the Python route that would make it easier for you to distribute it? Could you perhaps point me to an example or two of a Python package that is already included and might serve as a guide for my work?

C or Python makes no real difference to us. Packaging C application is easy but the same is true for Python applications.

If a Python application is distributed in the Python typical way packaging gets very easy as there are a couple of RPM build macros which do most of the steps for the packaging.

We currently have one package (EasyBuild) which does not yet use the typical Python packaging setup but we are trying to change that (#1597).

Examples of other Python code:

• https://github.com/openhpc/ohpc/blob/2.x/components/dev-tools/mpi4py/SPECS/python-mpi4py.spec
• https://github.com/openhpc/ohpc/blob/2.x/components/dev-tools/numpy/SPECS/python-numpy.spec

[jcsiadal]

I think Python would be fine, as long as it's compatible with the default Python3 included with both Rocky and OpenSUSE versions we support. In other words, stay away from any feature or module that's specific to particular subversion of Python3.

Should we enable PMIx Python bindings? The package is long due for an update to include PRRTE.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.