search

INCATools / ontology-development-kit

Bootstrap an OBO Library ontology
http://incatools.github.io/ontology-development-kit/
BSD 3-Clause "New" or "Revised" License
212 stars 53 forks source link

Publishing SSSOM mapping sets is broken #1036

Open gouttegd opened 3 months ago

gouttegd commented 3 months ago

Trying to get the ODK to publish the SSSOM sets that it manages, by adding the release_mappings: True option to the sssom_mappingset_group section in the config file, leads to the following error when running make prepare_release:

rsync -R   sssomo.owl   sssomo-base.owl   sssomo-full.owl    ../mappings/modmini-onta.sssom.tsv  ../mappings/modmini-ontb.sssom.tsv  ../mappings/modmini-ontc.sssom.tsv  ../mappings/modmini-ontd.sssom.tsv ../.. &&\
rm -f   sssomo.owl   sssomo-base.owl   sssomo-full.owl  tmp/merged-sssomo-edit.owl tmp/sssomo-preprocess.owl &&\
echo "Release files are now in ../.. - now you should commit, push and make a release \
        on your git hosting site such as GitHub or GitLab"
found ".." dir in relative path: ../mappings/modmini-onta.sssom.tsv
rsync error: syntax or usage error (code 1) at flist.c(2358) [sender=3.2.7]
rsync error: received SIGUSR1 (code 19) at main.c(1613) [Receiver=3.2.7]
make: *** [Makefile:300: prepare_release] Error 1

This is because the mappings are in src/mappings, while the rsync command that does the bulk of copying the release assets to the top-level directory is run from within the src/ontology directory. As a result, we are ultimately trying to do rsync -R [other release files] ../mappings/<mappingset>.sssom.tsv ../.., which rsync does not like at all – the -R option is incompatible with some source files being in any directory above the current directory.

Possible solutions:

1) Moving the mappings directory from src/mappings to src/ontology/mappings. Easiest solution, but a breaking change. And whether it is desirable to have the mappings in src/ontology is debatable.

2) Update the prepare_release rule to have a separate command that copies the mappings to the top-level directory (similar to what we already do for the patterns). This involves making sure the mappings to be released are not listed in the general RELEASE_ASSETS variable, but are instead listed in a separate variable (again, similar to what we do for the patterns).

gouttegd commented 3 months ago

@matentzn Can we make a decision quickly on this one? Should the mappings be stored in src/mappings or src/ontology/mappings?

Moving them to src/ontology/mappings would make the publishing feature (release_mappings: True) work with minimal effort. Downside: if an ontology has started using ODK-managed mappings since the release of version 1.5, then its mappings currently are in src/mappings and the ontology’s maintainers would have to move them when 1.6 comes out (or 1.6 would need to have some ad-hoc code in update_repo to automatically migrate the mappings to their new locations).

Keeping them in src/mappings avoids any breakage at all if an ontology has started using ODK-managed mappings, but will require deeper changes in the mappings-releasing workflow.

No strong opinion here. In any case, whatever we do, publishing mappings is going to remain broken until 1.6. But I want Uberon to start publishing its mappings sooner, and I would like to do it over there in a way that will be compatible with what 1.6 will do.

matentzn commented 2 months ago

My preference is 2. src/mappings is a good place, and I would rather fix the syncing code.