Provide Python library interface

[duncanmmacleod]

As discussed in https://github.com/fermitools/htgettoken/pull/40#issuecomment-1276748153, I think it would be extremely useful to expose a Python interface to htgettoken as well as the current shell executable interface.

This ticket is an epic metaticket that aims to track what I think are the necessary steps to achieving the above.

• [x] #35
• [x] #59
• [ ] Augment Python API to provide htgettoken.get_token() user interface

[duncanmmacleod]

@drdaved, I am hopeful that most/all of this can be done without greatly disrupting the current PyInstaller-based RPM distribution method.

I would be interested in helping to transition away from PyInstaller towards a standard dependency-based spec file if you are interested (I am prepared to enter Python dependency hell, as per https://github.com/fermitools/htgettoken/issues/35#issuecomment-1021338806).

[DrDaveD]

I don't want everybody else to have to deal with Python dependency hell, so I would be very wary of moving away from PyInstaller. I think your plan can be achieved without disrupting that.

[duncanmmacleod]

@drdaved, I have proposed #56 to directly address the PyInstaller issue, which is predictably failing.

I am new to PyInstaller, so have no real idea how to use it to generate a Python module, as opposed to a standalone executable. I'll keep reading and see if I can come up with something.

[DrDaveD]

I don't know that it can be used to generate a Python module. I would guess that would need to be done independently starting from the same source code.

[duncanmmacleod]

I have proposed a working removal of pyinstaller in #56, which I naively consider a prerequisite of the rest of the work proposed here (mainly because I don't understand pyinstaller at all).

[DrDaveD]

Are you wanting an rpm with a python library interface? Or would that be something that would be downloaded with pip? I don't see why pyinstaller has to interfere with separately having a python library interface, but maybe that's my ignorance of how pip installation works.

[duncanmmacleod]

@drdaved, I would want a Python library that is installable via RPM. Basically I would like {conda,dnf,pip,yum} install htgettoken to all yield basically the same thing.

[DrDaveD]

Pyinstaller does allow excluding specific libraries, so there could be an htgettoken-libs rpm that has just an htgettoken library, and all the rest could still be in the executable made by pyinstaller.

Even if there is a workaround for the kerberos library, the el7 python libraries tend to be very old, so if you use pyinstaller you can get the latest ones from pip. So I think using pyinstaller is more likely to reach your goal of having the same thing as pip.

[DrDaveD]

Oh, but I see that nobody else would be able to use the htgettoken-libs rpm if all its dependencies weren't also installed. So there's no point to that idea.

[DrDaveD]

Are the other two tasks in this epic metaticket finished now?

[DrDaveD]

Actually I think the second one is but not the third.

[duncanmmacleod]

Actually I think the second one is but not the third.

The second is provided by the linked PR (#59), but the third has not been implemented. I am pondering how best to go about this without aggressive refactoring of internal functions.

[duncanmmacleod]

@DrDaveD, in order to provide a Python interface like htgettoken.get_token(), the functions called by this interface should be independent of the 'global' state, so that this function can be called multiple times with, in general, different options, without confusion.

This basically means that all of the various (command-line) options will need to be translated into keyword arguments for all of the functions in which they are used, rather than relying on the options variable having global scope (not least because in the get_token() model there is no options variable in the first place).

I am happy to take on this task, but I think it's going to be fairly large, just a heads up (and a chance for you to veto).

[DrDaveD]

I'm OK with that.

[DrDaveD]

@duncanmmacleod Do you think you'll be able to get to task #3 pretty soon? I am contemplating adding a fairly significant feature for refreshing bearer tokens in a background process. I think it would be a lot easier if that goes into htgettoken 2.0 and if we developed the two features serially instead of in parallel.

[duncanmmacleod]

@DrDaveD, give me a week or so to work out my timescale. I agree that it's better if this all gets done in serial.

[DrDaveD]

@duncanmmacleod This has languished for too long. Will you be able to complete it soon? I have been getting requests to port htgettoken to el9 which would be easier to do when this is completed, but if it's still going to be a while I will need to instead adapt pyinstaller for el9. I have done a similar task for the embedded shoal-agent in frontier-squid so I pretty much know what to do, but still it would be mostly wasted work.

[duncanmmacleod]

@DrDaveD, sorry for the continual delays on this. I will do my best to get something done soon; attempting to do it in a more piecemeal way might allow you to proceed without waiting for me to finish 'everything'.

[DrDaveD]

@duncanmmacleod Are you going to be able to get back to this again?

Meanwhile I have updated v1 for el9, but it would really be good to stop using M2Crypto. I'm tempted to start backporting some of the changes to v1.

[duncanmmacleod]

@DrDaveD, unfortunately, I'm finding it hard to find the time for this. Also, when I have found the time in the past I have had a hard time identifying bitesize changes that can be made, so my brain starts trying to design a fresh implementation, for which I definitely don't have the time.

You should feel free to crack on with whatever you want and I can refactor any plans I have if I do find the time later.

[DrDaveD]

I'm thinking maybe to release it as-is, without your 3rd desired update "Augment Python API to provide htgettoken.get_token() user interface". Do you think there's a good reason not to release it?

[duncanmmacleod]

Do you think there's a good reason not to release it?

Do you mean to release from the current master branch? If you're happy, then by all means release.