You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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).
The text was updated successfully, but these errors were encountered:
@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.
Trying to get the ODK to publish the SSSOM sets that it manages, by adding the
release_mappings: True
option to thesssom_mappingset_group
section in the config file, leads to the following error when runningmake prepare_release
:This is because the mappings are in
src/mappings
, while thersync
command that does the bulk of copying the release assets to the top-level directory is run from within thesrc/ontology
directory. As a result, we are ultimately trying to dorsync -R [other release files] ../mappings/<mappingset>.sssom.tsv ../..
, whichrsync
does not like at all – the-R
option is incompatible with some source files being in any directory above the current directory.Possible solutions:
Moving the mappings directory from
src/mappings
tosrc/ontology/mappings
. Easiest solution, but a breaking change. And whether it is desirable to have the mappings insrc/ontology
is debatable.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 generalRELEASE_ASSETS
variable, but are instead listed in a separate variable (again, similar to what we do for the patterns).The text was updated successfully, but these errors were encountered: