expose flux version in python module

[vsoch]

Problem: Python tools that use Flux want custom logic based on the version, and we currently do not easily expose it.
Solution: create a flux.version "attribute" that calls into a module to call flux_core_version_string().

[chu11]

2023 :-)

[vsoch]

lol! @chu11 maybe I am living in the past... or maybe I just copy pasted from handle.py 😆

[chu11]

One random idea based on the slack conversation. If we can figure out why FLUX_CORE_VERSION_STRING is not being put into flux.constants, we could change this to just return flux.constants.FLUX_CORE_VERSION_STRING.

Granted flux_core_version_string() just returns that too, so saving that one function call is not much value. This is more about "why isn't FLUX_CORE_VERSION_STRING in flux.constants".

[vsoch]

Granted flux_core_version_string() just returns that too, so saving that one function call is not much value. This is more about "why isn't FLUX_CORE_VERSION_STRING in flux.constants".

We could definitely look into that, but I've done refactors of the Python bindings so many times, looking at the older version gives me the shivers. If someone has a hint / direction for where to look I can help, but I think my instinct right now is to run away! For context, we now have:

• https://github.com/flux-framework/flux-python/blob/main/setup.py vs https://github.com/flux-framework/flux-core/blob/master/src/bindings/python/setup.py
• https://github.com/flux-framework/flux-python/tree/main/src vs https://github.com/flux-framework/flux-core/tree/master/src/bindings/python/_flux

We can do changes in the older one, but just need to be careful to pass them forward to the more hardened one. Also, the separate bindings can easily ship with __version__ if we wanted, because they are built with the exact version of Flux (it happens in the CI). That said, I haven't gotten much feedback about the external bindings so I'm not really sure people are interested.

[vsoch]

Weird error:

Warning:  One or more build-args [BASE_IMAGE FLUX_SECURITY_VERSION GID IMAGESRC] were not consumed

[grondo]

If we can figure out why FLUX_CORE_VERSION_STRING is not being put into flux.constants,

I think the problem is that enumerated constants are the only thing put into flux.constants, all the #define constants are dropped. I know nothing about cffi, so I'm not sure if this is because cffi just can't handle defined constants or... @trws would probably know.

That is I presume why we have this in _core_preproc.py:

flux-core/src/bindings/python/_flux/_core_build.py

Line 32 in e915f2c

#define FLUX_JOBID_ANY 0xFFFFFFFFFFFFFFFF

[trws]

We may be filtering them out. CFFI does actually support defines, but only simple ones, and I may have just gone with avoiding the problem entirely rather than trying to pull in the ones that work.

…

On 20 Jun 2023, at 14:53, Mark Grondona wrote: > If we can figure out why FLUX_CORE_VERSION_STRING is not being put > into flux.constants, I think the problem is that enumerated constants are the only thing put into `flux.constants`, all the `#define` constants are dropped. I know nothing about cffi, so I'm not sure if this is because cffi just can't handle defined constants or... @trws would probably know. That is I presume why we have this in `_core_preproc.py`: https://urldefense.us/v3/__https://github.com/flux-framework/flux-core/blob/e915f2c492be9e16e7346c42176f256c7dc37480/src/bindings/python/_flux/_core_build.py*L32__;Iw!!G2kpM7uM-TzIFchu!w8Xes5bzPJvKYAkuE0LPcTn335L4eKkye6OfiJ3J_dDp00ViTQSZJgObyN4v5i-2nO3MVlsUiJ9fuNxvtMdrKJS1D3c$ -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/flux-framework/flux-core/pull/5281*issuecomment-1599614024__;Iw!!G2kpM7uM-TzIFchu!w8Xes5bzPJvKYAkuE0LPcTn335L4eKkye6OfiJ3J_dDp00ViTQSZJgObyN4v5i-2nO3MVlsUiJ9fuNxvtMdrbA4vWC8$ You are receiving this because you were mentioned. Message ID: ***@***.***>

[chu11]

We may be filtering them out. CFFI does actually support defines, but only simple ones, and I may have just gone with avoiding the problem entirely rather than trying to pull in the ones that work.

I initially thought this might have been a dumb thing, like we weren't including version.h somewhere. But since this may be a little trickier, I'll write up an issue as a TODO for later on.

[vsoch]

That sounds great, thanks @chu11 ! I directed the maestro developer how to get the version via an attribute, which should work for now. I also think they might just be calling flux --version to the command line, and the actual issue was being able to parse a git version (with the hasheedoo).

[garlick]

Since we opened #5285 to follow this up and the user has a workaround, it looks like the PR can be closed.