Rpm package python bindings

[engelmi]

This PR

• adds the pyhirte python module as a package to the hirte.spec
• fixes a typing issue in enable/disable unit in pyhirte.ext

[mwperina]

I'm not a python packaging expert, but I fear that we will not be able to build the package in Fedora if we use deprecated macros.
If we can't use the recommended python RPM macros with current build structure, which mixes C and python projects, then I'd suggest to have a different spec file for python package or completely different project.

[engelmi]

I'm not a python packaging expert, but I fear that we will not be able to build the package in Fedora if we use deprecated macros.
If we can't use the recommended python RPM macros with current build structure, which mixes C and python projects, then I'd suggest to have a different spec file for python package or completely different project.

@mwperina Mixing C and Python projects does not impact each other here. I migrated (again) from pyproject.toml to setup.py (which is deprecated) so that I was able to use these deprecated macros (e.g. py3_install) - even though I would prefer to use the new and recommended pyproject.toml. Using the pyproject.toml works fine building it via python -m build, but using the new rpm macros (e.g. pyproject_wheel) resulted in an UNKNOWN wheel - making the rpm build fail. Maybe upgrading from python3.9 to 3.11 would solve this, but I haven't tried it.

[dougsland]

I'm not a python packaging expert, but I fear that we will not be able to build the package in Fedora if we use deprecated macros.
If we can't use the recommended python RPM macros with current build structure, which mixes C and python projects, then I'd suggest to have a different spec file for python package or completely different project.

@mwperina Mixing C and Python projects does not impact each other here. I migrated (again) from pyproject.toml to setup.py (which is deprecated) so that I was able to use these deprecated macros (e.g. py3_install) - even though I would prefer to use the new and recommended pyproject.toml. Using the pyproject.toml works fine building it via python -m build, but using the new rpm macros (e.g. pyproject_wheel) resulted in an UNKNOWN wheel - making the rpm build fail. Maybe upgrading from python3.9 to 3.11 would solve this, but I haven't tried it.

IMO, If upgrade doesn't work, we can always "fly" in the first moment with something which works. Lets remember, we started with manually written python module and now we have a fancy auto generation module. Users will always appreciate initial features available. Or in other words, merge early, merge often.

[mwperina]

I'm not a python packaging expert, but I fear that we will not be able to build the package in Fedora if we use deprecated macros.
If we can't use the recommended python RPM macros with current build structure, which mixes C and python projects, then I'd suggest to have a different spec file for python package or completely different project.

@mwperina Mixing C and Python projects does not impact each other here.

Well, partially it is, because we are using non-standard project structure, that might be the reason why the preferred python macros doesn't work

I migrated (again) from pyproject.toml to setup.py (which is deprecated) so that I was able to use these deprecated macros (e.g. py3_install) - even though I would prefer to use the new and recommended pyproject.toml. Using the pyproject.toml works fine building it via python -m build, but using the new rpm macros (e.g. pyproject_wheel) resulted in an UNKNOWN wheel - making the rpm build fail. Maybe upgrading from python3.9 to 3.11 would solve this, but I haven't tried it.

IMO, If upgrade doesn't work, we can always "fly" in the first moment with something which works. Lets remember, we started with manually written python module and now we have a fancy auto generation module. Users will always appreciate initial features available. Or in other words, merge early, merge often.

This is not about upgrade, we want hirte packages for latest Fedora and El9, so we need to be able to adapt to different python versions (3.9 on EL9, 3.11 on FC37/38, 3.12 on rawhide).

If will try to take a look at the end of this week if we can make the spec working with non-deprecated macros ...

[engelmi]

Well, partially it is, because we are using non-standard project structure, that might be the reason why the preferred python macros doesn't work

Yes, its a non-standard project structure. However, in the spec I simply copy the pyhirte directory to root temporarily for the build/packaging - bringing it into the required structure (with lots of unnecessary files for the pyhirte package). Not sure if that is a good or bad approach, but I wouldn't want to have a pyproject.toml in the root directory (tracked by git).

This is not about upgrade, we want hirte packages for latest Fedora and El9, so we need to be able to adapt to different python versions (3.9 on EL9, 3.11 on FC37/38, 3.12 on rawhide).

Would El9 etc. reject the rpm macros? The built .whl is the same for both approaches. Not sure about the versions, though. I think for 3.12 the setup.py support is removed.

If will try to take a look at the end of this week if we can make the spec working with non-deprecated macros ...

That would be great!

[mwperina]

Let's merge now and if needed let's improve later