Open ferrigno opened 2 months ago
We haven't used this functionality anywhere for quite a while, so this function became incompatible with current dispatcher/plugin. And it stays untested as long as there is no more dispatcher/plugin in dependencies.
@ferrigno in which scenario do you need it?
@volodymyrss do we really want it like this, so that dispatcher/plugin is an optional dependency of nb2workflow?
@dsavchenko , I was trying to run a test notebook for my workflows following the suggested example.
I run it from my local virtual environment where I installed nb2worflow and dispatcher-plugin-nb2workflow from the git repository as suggested by @volodymyrss (I had to install also the dispatcher and I did it from the git repository)
You don't really need the dispatcher/plugin in this context. You won't encounter the exception if you remove them from the virtual environment. We still need to adapt this part, thought, so let's keep this issue open
I think the plugin was used to construct products from the test output, also verifying that the output annotation works.
That is, it should be used. It's not great to use a dispatcher plugin for this and it would be better to use product classes from oda-api. But I do not suppose its possible now, @dsavchenko ?
I can just confirm that I had to introduce the plugin because I encountered an error and could not obtain any result from the test. Removing it gives
unable to import dispatcher_plugin_nb2workflow.queries.NB2WProductQuery: No module named 'dispatcher_plugin_nb2workflow'
I can just confirm that I had to introduce the plugin because I encountered an error and could not obtain any result from the test. Removing it gives
unable to import dispatcher_plugin_nb2workflow.queries.NB2WProductQuery: No module named 'dispatcher_plugin_nb2workflow'
Unsurprisingly. You explicitly import it in test nb, but never use it after in fact
The explicit import was just left from a test, the error appears also without import.
https://renkulab.io/projects/astronomy/mmoda/isgri-expert/sessions/new?autostart=1&commit=bf08578d3050bce09000312050929d8692f03cde&branch=main you can run the notebook test from this session
There are both dispatcher and plugin in requirements. If you don't use them explicitly for some specific reason, you can remove both, then you won't encounter the exception.
I think the plugin was used to construct products from the test output
One can try to do it, but I don't think we ever did this explicitly.
It was used to test, how dispatcher "understands" annotations. But this information then isn't reflected anywhere as far as I remember (if available, it stays as variable in the container). Despite general problems with complicated requirements, this also increases the container size, which is rather big in any case.
I think the plugin was used to construct products from the test output
One can try to do it, but I don't think we ever did this explicitly.
It was used to test, how dispatcher "understands" annotations. But this information then isn't reflected anywhere as far as I remember (if available, it stays as variable in the container).
This was done and even sent by email, extracted from the container in here .
Would be nice to recover this functionality along with bot tests, else it is progressively harder to make sure the workflows remain valid.
Despite general problems with complicated requirements, this also increases the container size, which is rather big in any case.
It's true that it's better to do it from outside of the container, within oda-bot.
The import of nb2workflow is as suggested in the development guide ... at least when I started this project. The dispatcher plug-in is commented out. I let you discuss and solve this issue, as it goes beyond my field of competence. For me, it is just inconvenient that I cannot run a test as suggested.
The import of nb2workflow is as suggested in the development guide ... at least when I started this project. The dispatcher plug-in is commented out. I let you discuss and solve this issue, as it goes beyond my field of competence. For me, it is just inconvenient that I cannot run a test as suggested.
We are discussing with @dsavchenko what is the best next step for sustainable implementation, in relation to https://github.com/oda-hub/oda-bot/issues/38 .
If you @ferrigno want to help, you could maybe propose to make a change to the example or manual? To reflect your experience. Would be useful!
The import of nb2workflow is as suggested in the development guide ...
The nb2workflow is obviously needed, as it's directly used in tests. But one normally don't need any dispatcher-related dependencies in the session. Some of them may be eventually automatically used in the deployment process, thought
@anawas could you please try to run a test in your repository, run it, and see if you have the same issue. If yes (probably you will), try to fix it.
If not, please help @ferrigno with his repository, it's all the same mechanism.
I can reproduce the error on my machine. Additionally, I get the following warnings/error:
T1="2022-10-22T05:18:22.0" #http://odahub.io/ontology#StartTime --> Unknown datatype for owl_uri http://odahub.io/ontology#StartTime
T2='2022-10-22T23:10:16.0' #http://odahub.io/ontology#EndTime --> Unknown datatype for owl_uri http://odahub.io/ontology#EndTime
...
And there are complaints about unknown owl type uri such as
Unknown owl type uri http://odahub.io/ontology#Float. Creating basic Parameter object.
Unknown owl type uri http://odahub.io/ontology#String. Creating basic Parameter object.
Unknown owl type uri http://odahub.io/ontology#Boolean. Creating basic Parameter object.
Unknown owl type uri http://odahub.io/ontology#String. Creating basic Parameter object.
I am not sure if this is somehow related.
I corrected some wrong annotations in the parameter cell for both isgri and jemx expert repositories, but not T1 and T2, as they are valid ontology terms, also suggested in the development guide.
If I change the annotations of T1 and T2 into StartTimeISOT, the warning disappears, but the error in running with nb2workflow remains, so there is no relation.
This should be related https://github.com/oda-hub/dispatcher-plugin-nb2workflow/issues/111 . @anawas you can correct that class and it will help this issue.
I found the line in the code where the exception is raised. The class NB2WProductQuery
requires the argument ontology_path
(in project dispatcher-plugin-nb2workflow, file queries.py).
I found the line in the code where the exception is raised. The class
NB2WProductQuery
requires the argumentontology_path
(in project dispatcher-plugin-nb2workflow, file queries.py).1. What is this ontology_path? I cannot find either a documentation nor a type hint. 2. And where should this parameter be set?
It's a path to ontology file to be loaded. You can see in this case and in other similar cases how this is done in the tests.
You should be able to set a default published ontology path.
Just could you please cross-check that it is used as intended?
The follwing url return 404 when called. It's in file ontology.py
. https://raw.githubusercontent.com/FnOio/fnoio.github.io/master/ontology/0.4.1/function.ttl
What is it for? I wanted to use this url to get a default ontology.
In addition I wonder if this is the cause for the frequent not a turtle: None
messages.
https://raw.githubusercontent.com/FnOio/fnoio.github.io/master/ontology/0.4.1/function.ttl
That's not our default ontology. It was used for somehow unrelated purposes. @volodymyrss may have more insight Anyway, it's requested in try-except, so it can't raise issue.
Our ontology is served from https://odahub.io/ontology/ontology.ttl and this path is hardcoded as default in the code where applicable.
Yes, the fno is an old one. They have an update somewhere. But we should use our own (it has the references to upstream where suitable).
I can now run locally some of the tests here: astronomy/mmoda/mmoda-nb2workflow-example
. However, when I run Carlo's notebook (https://gitlab.renkulab.io/astronomy/mmoda/jemx-expert/-/blob/main/test_products.ipynb?ref_type=heads) I get a timeout for the following url, which seems not to be online:
dispatcher-staging.obsuks1.unige.ch
What is it used for? What is it supposed to return? I may need to write a mock for it.
that URL is available only in the virtual network of the University of Geneva. You can use the public endpoint https://www.astro.unige.ch/mmoda/dispatch-data instead
or use 'host_type' : 'production' instead of 'host_type' : 'staging'
The current version of the test NB at https://gitlab.renkulab.io/astronomy/mmoda/isgri-expert/-/blob/main/test_products.ipynb?ref_type=heads is updated. I am running it again so that you can get the products from the backend (for independent reasons, they are not anymore cached).
Introducing the oda_ontology_path dedfined in the file gives another error
this goes beyond my understanding.
[I used the master branch of all repositories with python 3.10