ENH: recommended dependencies numexpr and bottleneck should be managed extras in pandas setup.cfg

[JMBurley]

Is your feature request related to a problem?

Pandas installation guide strongly recommends packages numexpr & bottleneck. However, it provides no way to manage these dependencies nor let a package manager know that the version of numexpr & bottleneck on your container should be pinned to pandas. Given that setup.cfg provides a very convenient way to solve all of the above problems, we should solve them

Describe the solution you'd like

Use setup.cfg options as documented here to make numexpr & bottleneck optional extras for a pandas install.

Once this is done, a user will be able to ensure version alignment by

# in requirements.txt or setup.py
pandas[numexpr, bottleneck] == 1.22.4  # install pd 1.22.4 and compatible numexpr, bottleneck versions

The proposed solution is simple to do, simple to maintain, and already done by major libraries in similar situations (moto, aiobotocore).

Not having this solution wastes user time by forcing them to manually maintain versions of pandas dependencies that are not clearly linked to pandas, save in the brains of users and by manually referring to an install docs page.

I am happy to write the PR.

API breaking implications

None. This will simply make package management easier, and cause no changes to users who do not deliberately take action to enable this feature

Describe alternatives you've considered

• Can also achieve the same functionality by defining setup params in setup.py rather than setup.cfg. setup.cfg is more maintainable, but given that pandas already defines some extras_require in setup.py, it may be simplest to extend those requirements in setup.py (even though setup.cfg-based definitions are best practice).
• If highly recommended for pandas, numexpr, bottleneck could be made full dependencies. But clearly that is a major, breaking change that should not be taken lightly.

[mroeschke]

Thanks for the suggestion, I believe #39164 is a more general issue related to grouping optional dependencies, so closing in favor of centralizing discussion there.

[JMBurley]

Thanks for the fast response. #39164 is incredibly broad, the tasks are undefined and no-one has actioned it in the past 18 months. I absolutely agree with the ideas behind that issue, but will only address part of the issue now.

I'm going to solve the problem I've stated here and link both issues as a way of marking some progress. I may return to further action on #39164 later.