Open lpalbou opened 4 years ago
Possibly the package that I created some time ago could be sufficient: https://github.com/geneontology/curie-util-es5
Hi @lpalbou What dbxrefs are you removing ?
I am not removing anything at the moment, but pointing out that we have a duplicated db-xrefs.yaml which causes sync issue and inconsistencies.
My suggestion is to remove the one in amigo as the db-xrefs.yaml in go-site is the source of truth.
In the meantime, and since amigo is a much too big package to be included in a lightweight component (ribbon), I am using the js curie library with the go-site/db-xrefs.yaml. This will solve some of the issues we had in the past (eg ZFIN).
Where are the duplicated db-xrefs.yaml ?
If you follow the link in my ticket:
https://github.com/geneontology/amigo/blob/master/external/db-xrefs.yaml
https://github.com/geneontology/go-site/blob/master/metadata/db-xrefs.yaml
Ah got it ! You mean we have the same file twice - and not synch'ed :(
I wasn't aware of the AmiGO version. I have been editing the go-site version. Can we copy the file to AmiGO for now ?
Thanks, Pascale
I think it should be ok for now.
FYI I just did a diff between both files and there are a lot of differences. Checking with @kltm to see if there any requirement/change needed for the amigo/db-xrefs.yaml to work within amigo.
This is likely a dupe of https://github.com/geneontology/amigo/issues/564. To note again, this db-xrefs.yaml is not used for much practically and is a hangover from an ancient paradigm.
When amigo is refreshed with a new release, the db-xrefs.yaml should be getting updated as well. We can also do interim updates whenever we want.
It’s not the case. The PR I indicated over go-site/db-xrefs.yaml was about a year ago and the changes to ZFIN (see links in my original post) have never appeared in amigo/db-xrefs.yaml. If you do a diff between both files, you will see they are largely out of sync and ZFIN is just one of many examples.
I'm not quite following. If we go to: http://amigo.geneontology.org/amigo/gene_product/ZFIN:ZDB-GENE-050506-30 -> http://zfin.org/ZDB-GENE-050506-30, as in db-xrefs.yaml. The linking seems to work correctly. There is the issue of having that extra file causing confusion, which is #564 , but the source of truth remains the same.
Perhaps we could make a separate issue to track down and fix where the ribbon is getting data?
That's interesting. I checked rapidly and amigo is using the linker.js at least to some extent. And the "default" linker.js is definitely creating wrong URLs and is using the two years old amigo db-xrefs, resulting in that kind of URL: http://zfin.org/cgi-bin/ZFIN_jump?record=ZDB-GENE-030131-1033
See Alliance page / with field: https://www.alliancegenome.org/gene/ZFIN:ZDB-GENE-031118-139#function---go-annotations
However:
And seems like you are indeed downloading the correct db-xrefs during the amigo install: https://github.com/geneontology/amigo/blob/master/install#L326 . That's why amigo is still working.
But there are 24 repositories using amigo, if some of them (like the old ribbon) use the linker, they have the same issue and it's not an easy one to track. In case of fallback, the linker.js is indeed using the amigo/db-xref: https://github.com/geneontology/amigo/blob/master/install#L549
Your read of that file is a little incorrect: that is only triggered is the internet is not available (or other override is occurring). AmiGO installs and amigo2-instance-data builds pull db-xrefs.yaml from master
.
It sounds like you might be actually looking at the JS packages and related data. It could be that somebody is not using the most recent amigo2-instance-data
, which is the data package that feeds the linker. https://www.npmjs.com/package/amigo2-instance-data
I think that's what I said: it's a fallback. But the issue remains, there should be no duplicate (especially out-of-sync: use GitHub actions ?) of db-xrefs.yaml in amigo. This is creating side effects and we can not easily check and get into contact with people who might be using amigo2-instance-data.
I'm not sure what side effects you're referring to in this case, except for the annoyances covered in #564 . The generation and maintenance of amigo2-instance-data is an orthogonal issue. Certainly one that would be good to deal with, but not directly related to #564 . A separate issue could be to automatically deploy/release a compatible npm package as part of the pipeline release runs or similar and switch ourselves over to that. This is in my notes for Thursday.
Several reasons:
For references: zfin amigo; zfin go-site
To solve several issues with the new ribbon (which needs to solve those cross refs in a lightweight and up to date manner), I will probably publish a separate NPM package that could be reuse throughout apps.