Drop 32-bit - #14513

Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

• Do the proposed changes actually accomplish desired goals?
• Do the proposed changes follow the Astropy coding guidelines?
• Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
• Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
• Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see "When to rebase and squash commits".
• Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
• Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
• Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
• Is a milestone set? Milestone must be set but we cannot check for it on Actions; do not let the green checkmark fool you.
• At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

pre-commit.ci autofix

In Debian, we still have a number of official 32-bit architectures (ARM, i386, MIPS). Unless we run into massive test failures, I would like to keep Astropy available there; however this could probably be done as "32-bit is exotic now; don't put too much work into it".
However, I would ask to not remove 32-bit specific production code unless there is a specific reason for it. We should not artificially break 32-bit compatibility.
(not sure if this PR is the right place for this discussion; I probably missed the general one)

However, I would ask to not remove 32-bit specific production code unless there is a specific reason for it.

In general astropy developers are free (and encouraged) to simplify the code base when possible. We do this frequently with old code related to working around bugs in dependencies -- as we stop supporting the older version then we take out that workaround code. I think the same should apply to 32-bit workarounds. Even if @pllim doesn't specifically find them here, eventually that code will get excised.

After we remove tests that are specific to 32-bit platforms and CI 32-bit testing, then I'm not sure Debian should be even making 32-bit packages for the newer astropy releases. I would have guessed that a packager like Debian would adhere to stated package requirements like numpy >= 22.0 and now bits == 64.

We should probably talk only about removing i686, not all 32bits distributions ? Because win32 is still probably used a lot. I didn't find numbers so just a guess.

Numpy stopped distributing i686 wheels (in 1.22 I think ? I could'nt find a reference) but they still distribute win32 wheels.
@olebole - How do you deal with Numpy for i386/i686 ?

Debian compiles everything from the sources, so we don't depend on wheels. And Debian still has numpy 1.24 for all our 32-bit architectures (i386, mips, arm). From what I can see, there are no 32-bit specific patches in the Debian version, so probably upstream fully supports 32 bit and just dropped the wheels. A quick search got me to https://discuss.scientific-python.org/t/releasing-or-not-32-bit-windows-wheels for a discussion.

To avoid confusion: what Debian calls "i386" is in fact i686. i586 and below is not supported anymore by Debian.

A lot of small telescopes, etc control software was running on raspberry's and 32bit, so I would keep those users in mind before purging the 32bit parts just for the sake of spring cleaning.

I think the main motivation is that numpy doesn't have 32bit anymore and it is a required dependency. So, are you saying that I should hold off on this until our numpy minversion is 1.22? Our minversion is 1.21 now.

Thanks for all the feedback but all the opinions here differ and now I am confused on what the actual ask was. @astrofrog said it is okay to drop in main.

I think the main motivation is that numpy doesn't have 32bit anymore and it is a required dependency.

Not sure where this is sourced, numpy still builds 32bit windows wheels, and 32bit bits are still in the CI suite.

Yeah only win32 (https://pypi.org/project/numpy/#files). Does this mean we drop i686 but keep win32, as suggested above?

Just as Ole above, I'm mainly advocating for is to not artificially remove 32bit support from the code, whether it's tested with win32 or also with i686, I have no strong opinion about it.

So it seems Numpy still has a Linux 32bit CI job, e.g. https://github.com/numpy/numpy/pull/23360/checks?check_run_id=11868986979
Maybe we just remove the i686 wheels ? Better to keep a Linux job with 32bit if Debian still provides 32bit packages.

Okay, I'll close this and open a less controversial PR. I want the diff to stay here in case we have to revisit in the future. Thank you all for your valuable feedback!

See #14517