Feature request: Flux python bindings on Python path

[vsoch]

Currently when I am in the flux base container, I can't see flux python bindings without starting a flux instance:

docker run --entrypoint bash -it fluxrm/flux-sched:focal
python3 -c "import flux"

 fluxuser@20f8658bb2ea:~$ python3 -c "import flux"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'flux'

I suspect that starting the instance handles adding everything to python path or similar, so not starting it means we don't have that. Here is starting the instance:

flux start --test-size=4
python3 -c "import flux" # works

This is typically logical because I couldn't do anything with flux without the instance! However I have a case of starting a flux instance via the broker, and then having a (sort of "sidecar") service that I want to be able to interact with it. If I start the service via any kind of flux start / submit, then I either get only a small set of resources, OR I get WAY too many (e.g., imagine running a huge cluster and giving that many processes to a dinky web server? Probably a bad idea!) So in my testing, when I simply add the flux location to the Pythonpath in the container:

docker run --entrypoint bash -it fluxrm/flux-sched:focal
export PYTHONPATH=/usr/lib/flux/python3.8
python3 -c "import flux"

That actually works! I think as we get more complex use cases for this base container the flux bindings should generally be on the path, and the user can still learn they need to start the flux instance to use them. I did this for my base containers for the Flux RestFul API and didn't realize it wasn't present in the base image (until now).

And my use case isn't actually working yet - still strugglebussing along but I'm not giving up.

[grondo]

I apologize, but what's the request here? Having Python bindings in the default python path has more to do with how you install flux-core, rather than any change we could make in Flux or the bindings. However, I'm probably just not understanding what enhancement is being requested?

[vsoch]

Oh sorry I wasn't clear. I'm not sure where the flux container is build, but I think we should add:

ENV PYTHONPATH=/usr/lib/flux/python3.8

to address these use cases.

[grondo]

Oh, yeah, that makes sense. Actually I think Flux python bindings should be installed in the default PYTHONPATH of these containers, so I'll have to investigate what's gone wrong here.

[grondo]

I can reproduce this problem in the bionic container and it is because /usr/lib/python3.6/site-packages/ is not being added to the default sys.path:

$ python3 -m site
sys.path = [
    '/home/fluxuser',
    '/usr/lib/python36.zip',
    '/usr/lib/python3.6',
    '/usr/lib/python3.6/lib-dynload',
    '/usr/local/lib/python3.6/dist-packages',
    '/usr/lib/python3/dist-packages',
]
USER_BASE: '/home/fluxuser/.local' (doesn't exist)
USER_SITE: '/home/fluxuser/.local/lib/python3.6/site-packages' (doesn't exist)
ENABLE_USER_SITE: True

The issue seems to be that debian derived distributions use dist-packages instead of site-packages for installed python modules, but autotools assumes python modules go in site-packages so our modules are installed there.

Adding a site-packages.pth to /usr/lib/python3.x/dist-packages/ containing ../site-packages seems to work around this issue.

[grondo]

In 30 minutes or so the bionic and focal flux-core images should be rebuilt and you can test them @vsoch. If you need new images for flux-sched, we can then rebuild those by invoking the github workflow manually.

[vsoch]

yay, thank you (that was really speedy!)