I think pyvo 1.5 is still premature to require package wide, but we can certainly bump the version a bit and also require more recent version for alma.

Sure, if this is your strategy, although I don't see the clear benefit. Remind me please, is this just to accommodate users that pin their already installed pyvo version?

yes, this is to accommodate any users who are 1) cannot update for any reasons and 2) are not users of alma where features from a more recent pyvo is required (or irsa, as we do require 1.5 there, too)

I'm not sure how many are in this cross-section, but generally we don't require dependencies that are only a few months old.

OK, so I wasn't really on board with this, but now that we finally bumped support for python 3.7 and 3.8, I don't see anything else that the most recent pyvo would auto-upgrade.

So, while it's a bit orthodox, I don't see any reasons for holding back this requirement change (and in fact this would fix some of the SIA2 related issues users starting to to report when using some of the astroquery modules with an old pyvo version).

@keflavich - are you on board for requiring pyvo>=1.5?

Yes. My only concern is when installing into very old environments (CASA always packages with many years old python versions), I still want astroquery to function. But if this is solving real problems, sure, let's go ahead.

We already dropped the python versions here.

Could you maybe double check if python 3.9 is generally ok with them? We can dial it back to 3.8 if absolutely necessary, but keep supporting 3.7 was already became problematic

Let's not worry about supporting older versions. If astroquery happens to work when installed in those environments, great! But I don't want that to burden us or our CI.