catalog search handle from file edge case and implement max sources

[gibsongreen]

Description

This pull request is to address an edge case when there is only one source in a catalog search from file. It also implements the max_sources traitlet for all catalogs.

Change log entry

• Is a change log needed? If yes, is it added to CHANGES.rst? If you want to avoid merge conflicts,
  list the proposed change log here for review and add to CHANGES.rst before merge. If no, maintainer
  should add a no-changelog-entry-needed label.

Checklist for package maintainer(s)

This checklist is meant to remind the package maintainer(s) who will review this pull request of some common things to look for. This list is not exhaustive.

• Are two approvals required? Branch protection rule does not check for the second approval. If a second approval is not necessary, please apply the trivial label.
• Do the proposed changes actually accomplish desired goals? Also manually run the affected example notebooks, if necessary.
• Do the proposed changes follow the STScI Style Guides?
• Are tests added/updated as required? If so, do they follow the STScI Style Guides?
• Are docs added/updated as required? If so, do they follow the STScI Style Guides?
• Did the CI pass? If not, are the failures related?
• Is a milestone set? Set this to bugfix milestone if this is a bug fix and needs to be released ASAP; otherwise, set this to the next major release milestone. Bugfix milestone also needs an accompanying backport label.
• After merge, any internal documentations need updating (e.g., JIRA, Innerspace)?

[codecov]

Codecov Report

Attention: Patch coverage is 91.66667% with 2 lines in your changes missing coverage. Please review.

Project coverage is 88.84%. Comparing base (300e5f3) to head (1183d5d).
Report is 10 commits behind head on main.

Files with missing lines	Patch %	Lines
jdaviz/configs/imviz/plugins/catalogs/catalogs.py	91.66%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3337      +/-   ##
==========================================
+ Coverage   88.80%   88.84%   +0.04%     
==========================================
  Files         125      125              
  Lines       19132    19179      +47     
==========================================
+ Hits        16990    17040      +50     
+ Misses       2142     2139       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kecnry]

It looks like the entire GAIA search logic is uncovered - is it easy to add coverage here or if its out of scope, can you create a follow-up please?

Otherwise code looks good - thanks!

[kecnry]

can we have a warning for this (maybe in-UI)?

[gibsongreen]

I added a snackbar message instead of a warning since the user manually enters the max_sources themselves. Also added it for the Gaia (and SDSS) catalog with the custom logic for this.

[gibsongreen]

It looks like the entire GAIA search logic is uncovered - is it easy to add coverage here or if its out of scope, can you create a follow-up please?

A follow up ticket has been created and pulled into the sprint to add test coverage for Gaia and SDSS.
Update: There ended up being sources from Gaia for the existing test data that SDSS was using so I added the coverage in this PR.

[kecnry]

Code looks good - thanks!

[cshanahan1]

Tested this out, and I'm still seeing an issue when max_sources=1. If you select Gaia, max_sources=1, and 'search', nothing is added to the table or the viewer.

[gibsongreen]

Tested this out, and I'm still seeing an issue when max_sources=1. If you select Gaia, max_sources=1, and 'search', nothing is added to the table or the viewer.

Nice catch, I must've reverted something from a past commit! It should work now and I just consolidated the logic now since each of the catalogs now have the same logic route to add to table.

[cshanahan1]

Would it be faster to apply 'max sources' when going through astroquery, rather than cutting down the size of the table after? I'm not sure if it would if the table is being sorted and then returned, unless it's just returning the first n sources?

[gibsongreen]

Would it be faster to apply 'max sources' when going through astroquery, rather than cutting down the size of the table after? I'm not sure if it would if the table is being sorted and then returned, unless it's just returning the first n sources?

That was my thought too and so Gaia has the MAX_LIMIT variable where this is done and this is implemented, but SDSS documentation did not list having the same/a variable similar to Gaia so I went with slicing after the return which mimics the "From File..." handling for max_sources.