libjob: deprecate and remove flux_job_list() and flux_job_list_inactive()

[grondo]

The C wrapper functions for the job-list.list RPC: flux_job_list() and flux_job_list_inactive() are likely unused outside of test utilities, offer only a subset of functionality of the RPC, and can't be updated or extended without breaking ABI.

We should probably just somehow mark these functions as deprecated and remove them.

[chu11]

thought I'd try to deprecate flux_job_list() and flux_job_list_inactive() really quick. Updating the function calls with rpcs in cmd/flux-job relatively easy and pretty much all tests pass (1 test adjustment to deal with error check no longer handled by libjob). Warnings from tests in libjob/test can be dealt with via removing the tests.

Tricky part is how to deal with the warnings coming from the python bindings. Not sure if we'd want to remove the cffi inclusion of these functions or not, although I'd lean to their removal since people should not be using it . Right now the binding scripts gather all appropriate headers, scrape off comments and what not, and put them all together for cffi to do its thing.

Not sure of the best way to deal with this. If we had some type of comment field like NO_FLUX_PYTHON_BINDING, could sed/awk those functions away. Or could do some pre-processor trickery, like #ifdef NO_FLUX_BINDING and only define when we're doing the cffi magic (Edit: this is probably preferred, b/c we do a pre-processor step to generate the python bindings anyways).

Will leave this for another day.

[chu11]

Not sure of the best way to deal with this. If we had some type of comment field like NO_FLUX_PYTHON_BINDING, could sed/awk those functions away. Or could do some pre-processor trickery, like #ifdef NO_FLUX_BINDING and only define when we're doing the cffi magic (Edit: this is probably preferred, b/c we do a pre-processor step to generate the python bindings anyways).

Was just thinking about this and had a nifty idea on how to do this that might be easier, we could:

A) use some code formatter to make sure all functions are written on one line after the current pre-processing is done. B) "grep -v deprecated"

only negative is build would require said code formatting tool to be available. Dunno how good/bad that is.

Another option would be have some type of "blocklist", to say just skip these functions. Annoying to maintain, but perhaps the easiest option.

[chu11]

not sure why we didn't list flux_job_list_id() in the above, but I suspect that could be deprecated too??

[garlick]

What about adding __attribute__ ((deprecated)) to the C functions, and then logic in the python binding generation script to not generate bindings for functions with that attribute?

[chu11]

That was sort of my idea with the comment above about using some code formatter to put all function definitions on one line and I could just grep -v deprecated to get rid of those few functions.

My pre-processor hackery knowledge is limited, wasn't sure if there's a simple way to pre-process the headers so that it's easy to identify the functions that have the deprecated attribute assigned.

[garlick]

I thought there was already some code in the binding generator script to ingest multi-line function prototypes but I could be wrong.

[chu11]

I thought there was already some code in the binding generator script to ingest multi-line function prototypes but I could be wrong.

I think what surprised me is that I thought some table of stuff would be built up and then that table could be updated/modified etc. Maybe there's a way to do it that way and I just don't know cffi that well. But instead, you basically just slurp up the whole header file in one fell swoop into cffi.

with open("_core_preproc.h") as h:
    cdefs = cdefs + h.read()

ffi.cdef(cdefs)
if __name__ == "__main__":
    ffi.emit_c_code("_core.c")