Possible bug down the dependency chain in owmeta.
Closed this issue · 7 comments
If this issue is intended to be a bug report, please fill out the following:
Expected behavior
Successful build.
Actual behavior
Error building for owmeta (PyOpenWorm) as follows:
#13 50.70 from rdflib.plugins.memory import IOMemory
#13 50.70 ModuleNotFoundError: No module named 'rdflib.plugins.memory'
executor failed running [/bin/sh -c git clone https://github.com/openworm/PyOpenWorm.git && cd PyOpenWorm && git checkout ow-0.9 && sudo apt-get install -y python3-cffi && sudo python3 setup.py install && pow clone https://github.com/openworm/OpenWormData.git]: exit code: 1
Steps to reproduce the behavior
run ./build.sh after fresh checkout as per documentation instructions.
Ok some version of rdflib appears to have deprecated access to rdflib.plugins.memory. Changing the setup.py in owmeta to use rdflib==4.1.2 from rdflib>=4.1.2 fixes this problem. This will need to change to a properly bounded requirement for the owmeta ow-0.9 branch. I will raise an issue with the owmeta repository and then close this issue once that's fixed in owmeta.
Edit: Forgot to note that the current build will default to rdflib==6.0.0 without a proper bound on the version support.
@cheelee owmeta and owmeta-core should be as unconstrained about dependency versions as possible. I limited to rdflib<6.0.0 since IOMemory was moved and renamed in 6.0.0 on ow-0.9 branch. For owmeta-core, I'll see if I can keep support for both rdflib<6 and rdflib==6. I'll backport to PyOpenWorm ow-0.9 if it's easy enough.
@mwatts15 Agreed. I think good practice may be for the latest owmeta release (e.g. 0.0.x) to begin its life cycle with an open range (e.g. rdflib>=6). CI/CD will then ensure that it remains bug free with the latest dependencies.
Finally if some dependency does deprecate features, we could cap off the range for that dependency.
Also if we make a new owmeta release, we could do a final update to the dependency requirements of the old owmeta version by capping off each of owmeta's dependencies by their latest bug-free versions.
I wonder if there is some automated way of handling this. The above protocol should ensure that each released version of owmeta is dependency-safe.
What had initially caught me by surprise was that the build failure showed up for OpenWorm docker in spite of no changes to the current release, and I had also correctly assumed that there were no changes to PyOpenWorm ow-0.9.
Anyway thank you very much for looking into a backport. We can close this issue once the backport goes into effect for PyOpenWorm, and I make a new test for OpenWorm/OpenWorm.
@cheelee I think that's basically my strategy: assume we're compatible until I get evidence we aren't, then add constraints for breakage if I can't easily patch. I probably would have caught this one a little sooner, but I haven't yet restored a working CI build for owmeta-core.
I can try to help with any specific CI/CD issues if it is something that can be parcelled out and can help with your workload.
@cheelee Thanks. I've got the owmeta-core Github Actions workflow going now, so getting owmeta running again should be pretty straightforward.
I added the version constraint on the ow-0.9 branch, but I'm not going to put any effort into making that work with rdflib>=6.0.0: I would end up fixing things I already fixed and improved upon in owmeta. The development_c302 branch has started the change to owmeta and I'm working on the update now.