Python requirements: Need `oaklib>=0.5.20`

[joeflack4]

A new oaklib release came out that has things that I need. Any chance we can get an image out with this version pre-installed?

I wasn't sure if there was any way to make this request via a PR (if that's possible, since the requirements files aren't / don't really need to be versioned).

[gouttegd]

We have just released 1.4.3 two days ago, so I am not keen on making a 1.4.4 release so soon after that just to update one Python module, regardless of how useful that module is (but ultimately, though I am the maintainer of the 1.4 branch, @matentzn is the one doing the actual builds, so he’s the one calling the shots).

In the meantime, your options are (by order of preference, in my opinion):

• keep using the latest released ODK and upgrade oaklib yourself when running it (basically, make sure that a python -m pip install -U oaklib is executed at some point early in your workflow);
• build your own local image of the ODK, forked off the 1.4.3 release and with just the change(s) that you need;
• switch to the dev version of the ODK, which by next week (when the Python constraints will be updated) should automatically include the latest oaklib.

For what it’s worth I strongly discourage the latest option. You would not only get the latest oaklib but also all the ongoing changes that have happened in the main branch since the 1.4.0 release – some of them being possibly still under development and not ready for prime-time yet.

[balhoff]

Did we end up following this plan? https://github.com/INCATools/ontology-development-kit/issues/764

Meaning—is it lower burden now to put out frequent software update releases?

[matentzn]

Yes, much lower.. But not so low to say we just do it every week - but yea, so far I think we made a software update release once per month!

[cmungall]

@gouttegd's suggestion works well for OAK or any other python lib in ODK

keep using the latest released ODK and upgrade oaklib yourself when running it (basically, make sure that a python -m pip install -U oaklib is executed at some point early in your workflow);

[gouttegd]

works well for OAK or any other python lib in ODK

Be aware that it may not work on arm64 for Python packages that are at least partially written in a compiled language (i.e., non “pure Python” packages), if the authors of said packages don’t provide a pre-compiled “wheel” for arm64. In that case you may need to fallback to the second preferred solution (build your own local image of the ODK).

No problem for oaklib, though, for which arm64 wheels are available.

[joeflack4]

I'm fine with this solution; I am aware of it and was already doing it:

keep using the latest released ODK and upgrade oaklib yourself when running it

Certainly it is preferable though if the upgraded version is already in the container.

But, question: When this happens to me in the future, I suppose I should not make a GitHub issue about it? I should simply wait until the next (supposedly monthly) release, and it will automatically come with the latest version of every package? Or?

[gouttegd]

When this happens to me in the future, I suppose I should not make a GitHub issue about it?

For what it’s worth, I don’t think so. I think you should never refrain from letting us know what would be useful for you.

[gouttegd]

Closing as the ODK is now providing oaklib 0.5.25.