-
-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace list_services by list_interfaces #525
Conversation
888b6a6
to
9d22eec
Compare
On Mon, Feb 19, 2024 at 02:03:12AM -0800, Manon Marchand wrote:
This PR addresses #521
Thanks -- just reading the diff I've not noticed anything I'd
consider untoward.
However, I still think we should use this opportunity to amend the
output of describe(). There, it currently says:
if len(self._mapping["access_urls"]) == 1:
print("Base URL: " + self.access_url, file=file)
else:
print("Multi-capability service -- use get_service()", file=file)
…-- and I think we should change that such that it says:
Service Capabilities:
* <description, with generic fallback> (Cone Search)
* <description, with generic fallback> (Cone Search)
* <description, with generic fallback> (TAP)
(infrastructure capabilities like VOSI and *possibly* datalink should
probably not be shown).
Since we're now hitting the Registry for describe() anyway, I'd at
least think hard whether this should refresh the information from
RegTAP; the advantage would be that .describe output would be
constant against Servicetype constraints, which would *probably* a
minor advantage. The interfaces retrieval I could write myself when
the rest is there, though.
|
fe2cc40
to
e598610
Compare
What about something like :
there's nothing when there is no description. By looking into a few records, there is no description when it is a bit obvious. I don't print vosi, datalinks and soda. Do you think I should have kept soda? |
e598610
to
4afb05a
Compare
On Mon, Feb 19, 2024 at 07:57:49AM -0800, Manon Marchand wrote:
What about something like :
I think I like the output; I'd use subsequent_indent=' ' in the
textwrap call so the continuation lines line up, though.
Similarly nitpicking: I'd probably re-use is_vosi in ignoring
interfaces for description, somewhat like this:
if (interface.is_vosi
or interface.standard_id.split("#")[0] in {'soda', 'datalink'}):
continue
It's probably a bit less mystifying, and I'm *a bit* worried about
"str in otherstr" overmatching.
Perhaps we should even have a method is_user_visible() in Interface
that would encapsulate that whole visbility logic?
I don't print vosi, datalinks and soda. Do you think I should have
kept soda?
As long as we don't return anything useful to users from get_service,
I think it shouldn't be in describe.
Thanks!
[oh, I've not investigated the CI failures]
|
(The failure in the devdeps CI looks like something that changed in the dev version of numpy, so not related. There is also the changelog but I think that one is not up to me, looks like a missing label?) I like the is_user_visible idea! |
On Mon, Feb 19, 2024 at 10:21:51AM -0800, Manon Marchand wrote:
I like the is_user_visible idea!
Let's keep it in mind. Or perhaps we should have the inverse:
is_infrastructure. That sounds a bit clearer to me, and if better
follows the code logic, which is "check in a list of things that
don't make much sense for get_service". Each "not" in a logic is a
potential brain teaser in my experience...
|
I did not like the "not vosi, not datalink..." approach, so I went with the keys of the "service_for_standardid" dictionary. This would need to be updated anyway if the services change. It should keep things easier to maintain. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've left a few comments that boil down to matters of taste -- and I'm happy to have this merged in its current state, too.
On Tue, Feb 20, 2024 at 02:15:21AM -0800, Manon Marchand wrote:
I did not like the "not vosi, not datalink..." approach, so I went
with the keys of the "service_for_standardid" dictionary. This
would need to be updated anyway if the services change. It should
keep things easier to maintain.
Good point.
|
I think I addressed all your comments 🙂 |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #525 +/- ##
==========================================
+ Coverage 79.71% 80.38% +0.66%
==========================================
Files 52 52
Lines 6178 6189 +11
==========================================
+ Hits 4925 4975 +50
+ Misses 1253 1214 -39 ☔ View full report in Codecov by Sentry. |
On Thu, Feb 22, 2024 at 06:42:17AM -0800, Manon Marchand wrote:
@ManonMarchand commented on this pull request.
+ # a service is user visible if it has a corresponding service class
+ if self.standard_id is not None and self.standard_id != "":
The remote data document tests fail without it. Looks like some non
standard services have an empty string in self.standard_id. I did
not investigate further than adding this condition.
Ok... the old pain of "" and None not being distinct in VOTables, I
suppose. I wonder if I should debug this and (presumably)
standardise on standard_id being None and never "", but for let's
keep it like this, then.
|
On Thu, Feb 22, 2024 at 06:47:23AM -0800, Manon Marchand wrote:
I think I addressed all your comments :slightly_smiling_face:
Let's go, then. @bsipocz, if you agree, would you merge? Thanks all
around!
|
Oh, of course, you don't need to wait for me to merge things that are reviewed and ready to go. However, I added some changelog conflicts with the v1.5.1 release this morning, so will go ahead fix that conflict and then merge. |
…aces objects rather than Services This prevents the instantiation of service objects that won't be used. The service can be accessed with the to_service() method.
it was only printing an url when there was a single acess point before.
is user visible corresponds to services that can be instantiated in pyvo and webpages. This is called in 'describe' and in 'list_interfaces'.
4f1df7f
to
c2c38ee
Compare
Thanks @ManonMarchand! |
This PR addresses #521
The
list_services
method is removed and replaced bylist_interfaces
to prevent the instantiation of Service objects that wouldn't be used.The repr of the class Interfaces (added in #505 so not impacting the released version) is now lighter/shorter.