Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NEVER MERGE: ROBOT plugin testing #9952

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 32 additions & 1 deletion src/ontology/hp.Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -132,8 +132,15 @@ reports/hp_xrefs.csv: $(SRC)
###### SKIP DEFAULTS #############
##################################

$(EDIT_PREPROCESSED): $(SRC)
# Instead of making the prepare-robot-plugins a dependency, we just call the goal
# to update the plugins when we need it
$(MAKE) prepare-robot-plugins
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may be preferable to putting it into the dependencies (as it is a phony goal). The symlinks are very fast, and the other plugins are only updated when the make cache is invalidated first.

$(ROBOT) monarch:upheno-augment -i $< --relation has_phenotype_affecting \
convert --format ofn --output $@

# We overwrite the .owl release to be, for now, a simple merged version of the editors file.
$(ONT).owl: $(SRC)
$(ONT).owl: $(EDIT_PREPROCESSED)
$(ROBOT) merge --input $< \
annotate --ontology-iri $(URIBASE)/$@ --version-iri $(ONTBASE)/releases/$(TODAY)/$@ \
convert -o [email protected] && mv [email protected] $@
Expand Down Expand Up @@ -636,3 +643,27 @@ $(TMPDIR)/hp-%-merged.owl: hp-base.owl tmp/%.owl

mappings:
$(MAKE_FAST) ../mappings/hp-snomed.lexmatch.sssom.tsv

###########################################
### Testing new custom plugin system ######
###########################################

# Make sure ROBOT knows where to find plugins
export ROBOT_PLUGINS_DIRECTORY=$(TMPDIR)/plugins

# List of "repository plugins" (plugins permanently installed in top-level plugins directory, entirely managed by users)
ROBOT_REPOSITORY_PLUGINS=$(wildcard ../../plugins/*.jar)

# Standard rule to create symlinks in $(TMPDIR)/plugins, so that the repository plugins
# are visible to ROBOT
prepare-robot-plugins:
for plugin in $(ROBOT_REPOSITORY_PLUGINS) ; do ln $plugin $(TMPDIR)/plugins ; done
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does not throw an error when the ../../plugins directory does not exist, which is good.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But this will throw an error if there are some plugins in the ../../plugins directory but the destination directory ($(TMPDIR)/plugins) does not exist. We need a mkdir -p $(TMPDIR)/plugins before attempting to create the symlinks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! Just unix 101: what happens if a file is deleted in ../../plugins/*.jar after this is run? Does the seem link disappear as well?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. We’re creating a normal link here, not a symbolic one (or a “hard” link instead of a “soft” one) – my mistake in the previous comment for calling them “symlinks” out of habit.

If the original file in ../../plugins/ is deleted, the newly added link in $(TMPDIR)/plugins will still be there, and will still point to the same contents (technically the same inode) on the disk.

(FYI: The reason we are creating normal links instead of symbolic links is that for some reasons, from within the ODK ROBOT would not be able to correctly follow the symlinks, even if both the symlinks and the files they are pointing to are both visible from the container – I’ve tried.)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’ll be curious to see whether this works as expected on Windows, though. AFAIK Windows has no such concepts as links and inodes, so I don’t know how Docker on Windows will handle that…


# in the custom.Makefile, users can simply attach any custom plugins they need
# as dependencies to the prepare-robot-plugins goal
prepare-robot-plugins: $(ROBOT_PLUGINS_DIRECTORY)/monarch.jar
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

renamed the goal a bit. Similar to test goal, custom Makefile extenders can simply attach the custom modules to that goal if they need to


$(ROBOT_PLUGINS_DIRECTORY)/monarch.jar:
mkdir -p $(ROBOT_PLUGINS_DIRECTORY)
# Ignore this obviously this will be replaced by a download step
cp ~/ws/robot-phenotype-toolkit/target/robot-plugins-0.0.1-SNAPSHOT.jar $(ROBOT_PLUGINS_DIRECTORY)/monarch.jar
Loading