Update Numpy minimum version to 1.17.0

[PrimozGodec]

Based on the discussion in #3137 I am updating the minimum NumPy version to 1.17.0. It is required since otherwise users who install Gensim in the environment with an older NumPy version get AttributeError: module 'numpy.random' has no attribute 'default_rng' error.

[piskvorky]

Thanks!

Numpy 1.11.3 is almost five years old; 1.17.0 is two years old. I guess we can do this – recent versions are fine because ML people generally update to cutting edge anyway. WDYT @mpenkov @gojomo ?

[mpenkov]

No objections from me.

[gojomo]

NEP 29 implies the Numpy project has already (as of January 2021) dropped support for every version earlier numpy-1.17.

It'd be logical to never do a formal release that specifies an expired-support version of Numpy - so I'd be fine bumping to 1.17 ASAP.

We may even want to go further, and always ensure our releases specify a Numpy version that has at least N months of support remaining, where N could be 3, 6, or even 12.

[piskvorky]

Okay, merged. Congrats on your first Gensim contribution @PrimozGodec ⭐

@gojomo is there a way to automate that? If the process relies on us (or users) manually submitting version edits to setup.py, like in this PR, we're bound to forget.

[gojomo]

I don't know of a standard way to integrate a project's "oldest supported" or "oldest supported as of a certain date" version - it seems those expectations are still somewhat informally specified, as through that 'NEP', rather than rigorously specified.

I could imagine some new convention where a project, at a well-known & relatively-secure URL under its management, might maintain text fragments specifying key transitions of support. For example, perhaps https://numpy.org/earliest-supported.ver might have just the string, numpy=1.17.5 # released 2021-01-01; end-support 2021-07-25. Similarly, paths /latest-supported.ver & other variants might include useful strings, allowing downstream projects like us (or projects downstream of us) to auto-fetch recommended versions of things before releases or testing. (Maybe there is something like tis or some other level of labeling on PyPI that might provides such hints - but I don't recall coming across it.)

Barring something that reliable, adding to a checklist for new releases a quick review of major prerequisites (like numpy/scipy) for changed supported-status.

[piskvorky]

Thanks, makes sense. Could you add that step to the release checklist please (with a link to this PR, for context)?

[gojomo]

Where is a release checklist, if any? (A search of the repo reveals no files ith 'checklist' in them.)

[mpenkov]

https://github.com/RaRe-Technologies/gensim/wiki/Developer-page

[gojomo]

I've added an item with the gist-of-the-check at: https://github.com/RaRe-Technologies/gensim/wiki/Developer-page#prepare - review & adjust as desired.

Since our earlier discussion, I came across scipy's oldest-supported-numpy meta-package: https://github.com/scipy/oldest-supported-numpy

It seems more focused on being a build-prereq for wheels, not an end-user-install-time prereq - so I'm unsure whether it changes our concerns here.... but it's interesting to know about, as a formalized way to express upstream-dependency lifecycle states.

[mpenkov]

Yeah, we use oldest-supported-numpy for building gensim wheels for releases, but as you've stated, they solve a slightly different problem than the one mentioned by the OP.