Mango next - #698
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #698 +/- ##
==========================================
- Coverage 84.09% 84.03% -0.07%
==========================================
Files 80 79 -1
Lines 8556 8529 -27
==========================================
- Hits 7195 7167 -28
- Misses 1361 1362 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
bsipocz
left a comment
There was a problem hiding this comment.
Some minor nitpicking comments
| sparse: boolean, optional (default to False) | ||
| If True, all properties are added in a independent way to the the TEMPLATES. | ||
| They are packed in a MangoObject otherwise. | ||
| schema_check: boolean, optional (default to True) |
There was a problem hiding this comment.
We need to run a docs format checker (to be done separately from this PR), this is just a reminder mostly to myself to do it (these white spaces affect the actual API docs rendering)
| schema_check: boolean, optional (default to True) | |
| schema_check : boolean, optional (default to True) |
There was a problem hiding this comment.
Fixed, but I found out tens of occurrences of this pattern (/[a-z]: /) in many files. I prefer to have your green light before to increase the number of modified files. Could this be done in a specific PR?
There was a problem hiding this comment.
yes, let's not mix those changes into this PR but do it separately, and I'll also try to remember to pick a tool that does that linting for us.
There was a problem hiding this comment.
I'll open a dedicated PR once this one will be merged.
|
|
||
|
|
||
| @prototype_feature('MIVOT') | ||
| class XMLViewer: |
There was a problem hiding this comment.
This was a prototype, so I suppose changing the API without any prior notice is fine and thus this can be removed without deprecation. But this class was mentioned in the narrative docs, so it's just something to be aware of.
There was a problem hiding this comment.
made it more explicit in the change log
| raise MivotError( | ||
| "Can't find " + Ele.INSTANCE | ||
| + " in " + Ele.TEMPLATES | ||
| ) |
There was a problem hiding this comment.
absolute nitpicking, but I feel this could all fit in one line; we're quite liberal with line lengths and allow them to be up to 110 characters
tomdonaldson
left a comment
There was a problem hiding this comment.
Thanks very much for this @lmichel! It's very exciting to see this working so cleanly with real services. Other than the minor comments I left, I'm very comfortable merging this to make it available for people to try out.
I left a number of minor comments, mostly coming from minor issues I encountered while working through viewer.rst and example.rst. Please have a look and address the ones that make sense to you. If any of the comments make sense but are difficult to resolve, then they can be left for later, because it will be good to have this functionality merged.
bsipocz
left a comment
There was a problem hiding this comment.
I see some of Tom's comments haven't got addressed (they are kind of hidden under a "hidden conversation" button. I assume you haven't seen them and they got just accidentally left out. I'm happy to work them in, as I plan to rebase before merge anyway due to a duplicated commit in the history.
Let me know if my read of the situation is correct, so I'll go ahead with the minor fixes and merge this.
| print(mivot_instance.__dict__.keys()) | ||
| dict_keys(['dmtype', 'longitude', 'latitude', 'pmLongitude', 'pmLatitude', 'epoch', 'Coordinate_coordSys']) | ||
| # dict_keys(['dmtype', 'longitude', 'latitude', 'pmLongitude', 'pmLatitude', 'epoch', 'Coordinate_coordSys']) | ||
|
|
||
| print(mivot_instance.Coordinate_coordSys.__dict__.keys()) | ||
| dict_keys(['dmtype', 'dmid', 'dmrole', 'spaceRefFrame']) | ||
| # dict_keys(['dmtype', 'dmid', 'dmrole', 'spaceRefFrame']) | ||
|
|
||
| print(mivot_instance.Coordinate_coordSys.spaceRefFrame.__dict__.keys()) | ||
| dict_keys(['dmtype', 'value', 'unit', 'ref']) | ||
| # dict_keys(['dmtype', 'value', 'unit', 'ref']) |
There was a problem hiding this comment.
Tom suggested this to allows users to cut/paste working code snippet
There was a problem hiding this comment.
If we add these as code examples for doctest, then the copybutton sphinx extension (>>> arrows on the top right corner of the box) takes care of ripping out the print results.
Try this one: https://pyvo.readthedocs.io/en/latest/mivot/viewer.html
So, overall I would rather suggest to have these formatted with the >>>s included
There was a problem hiding this comment.
I replaced all .. code-block with .. doctest-skip::
|
I ran through the doc code again and am quite happy with it. I did just push one minor fix where |
| for globals_instance in m_viewer.dm_globals_instances: | ||
| print(globals_instance) | ||
|
|
||
| .. code-block:: json |
There was a problem hiding this comment.
Why json and not Python dictionary? json should be a serialization method.
There was a problem hiding this comment.
The json flag was here to tell Sphinx how to highlight the syntax.
I replaced all code-block with .. doctest-skip:: as suggested bu @bsipocz anyway
There was a problem hiding this comment.
No, it's not about docs it's about the format that print(globals_instance) produces. I expected to be something more concise so that the user would be able to do log.debug("Process globals_instance: " + globals_instance) or similar and have it show up in a single row.
There was a problem hiding this comment.
I see.
I put a single line string representation (<MivotInstance: dmtype="mango:EpochPosition">) for MivotInsance.
The whole representation (dictionary) is now only used by repr()
| Python object generated from the MIVOT block as either a Pyhon object or a dict | ||
| ''' | ||
| self._mivot_instance_dict = mivot_instance_dict | ||
| if isinstance(mivot_instance, dict): |
There was a problem hiding this comment.
Again, no point for 2 alternative types for model representation. End users are interested in actual MANGO or other astronomy related objects (SkyCoords) not the model representation. Just my opinion.
There was a problem hiding this comment.
this is mostly driven by the will of simplifying unit tests
There was a problem hiding this comment.
This feature has been removed
| >>> | ||
| >>> # Print out the json serialization of the Python object | ||
| >>> print(mango_property) | ||
| { |
There was a problem hiding this comment.
My suggestion is to not expose the model representation to the user. I don't recall but it must be a way to either specifically request MANGO model classes or to discover the ones that are available. The "discovery" mechanism can be either an explicit "get all the types" or simply trying, e.g. check wether getSkyCoord(row) which looks for the dm_instance.dm_type=mango:EpochPosition and returns the corresponding sky coordinates or null otherwise. But the mangoProperty is just a serialization representation.
| self._mivot_instance_dict = mango_property | ||
| return self._build_sky_coord_from_mango() | ||
| raise NoMatchingDMTypeError( | ||
| "No INSTANCE with dmtype='mango:EpochPosition' has been found:" |
There was a problem hiding this comment.
Or simply return None. I'm not sure which one is better as a discovery mechanism.
There was a problem hiding this comment.
honestly, I've no preference. I can change this if you wish.
Using exception:
- PRO: Give a clear view on the reason of the failure
- CON: Break the current execution thread
| <VODML xmlns="http://www.ivoa.net/xml/mivot"> | ||
| <REPORT status="OK"/> | ||
| <MODEL name="ivoa" url="https://www.ivoa.net/xml/VODML/IVOA-v1.vo-dml.xml"/> | ||
| <MODEL name="coords" url="https://ivoa.net/xml/VODML/Coords-v1.vo-dml.xml"/> |
There was a problem hiding this comment.
https://ivoa.net/xml/VODML/Coords-v1.0.vo-dml.xml - the correct URL
| scb = SkyCoordBuilder(mivot_instance) | ||
| scoo = scb.build_sky_coord() | ||
|
|
||
| assert (str(scoo).replace("\n", "").replace(" ", "") |
There was a problem hiding this comment.
This is fragile subject to astropy changing their representation format. It should check the values instead.
bsipocz
left a comment
There was a problem hiding this comment.
Some more minor comments, they are not blockers or really actionable here, but we may nevertheless sort them out in a follow-up -- e.g. about the skipped tests.
Also, there is a failure on the devtest job, I'll have a look at that before merging this (aiming by this evening (CET time) and cutting a release (aiming tomorrow evening or on Wednesday the latest)).
(and will rebase to clean up the duplicated commits -- again, no action items for you there).
|
|
||
| .. doctest-skip:: | ||
|
|
||
| >>> import pytest |
There was a problem hiding this comment.
I don't think we should have any pytest machinery for skipping in the narrative docs examples, it could be said at the top that one needs a x.y astropy to run these examples (and as they are skipped anyway it won't be an issue for out actual testing (or also we can use doctest requires at the top of the files.)
| >>> from pyvo.dal.scs import SCSService | ||
| >>> from pyvo.utils import activate_features | ||
| >>> from pyvo.mivot.viewer.mivot_viewer import MivotViewer | ||
| >>> from pyvo.mivot.features.sky_coord_builder import SkyCoordBuilder |
There was a problem hiding this comment.
This is not an issue at all, but I would think that in narrative documentation there is a benefit of doing the imports at piecemeal -- only in the cells where they are (first) used, where the classes/functions are being first described as opposed to doing everything at the top.
There was a problem hiding this comment.
agree, to be fixed later
To be continued accordingly to the MANGO recommandation process
to access remote resources
Glossary - improve the test coverage
with local resources only
…) or from a MivotInstance
annotated Vizier CS + a few other minor cosmetics
doctest in example.rst
one (whole dictionary) is still in use as a repr()
of the current PR (+flake8)
|
Thank you @lmichel! |
|
A big thank you to the reviewer team |
This MR only relates to the annotation readout.
Code cleaning:
MivotViewer:
This PR improves the current API. It will be extended with model specific modules once MANGO will be a REC. At that time new MANGO-specific features will be completed.