-
Notifications
You must be signed in to change notification settings - Fork 9
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
Add requires_openeye
decorators when oechem
is used
#275
Conversation
requires_openeye
decorators when openeye
requires_openeye
decorators when oechem
is used
4ee8831
to
a6d1cb7
Compare
Thanks @mattwthompson, I think we just need to catch this new exception here and here for this to work and ill give it a test run! |
Ah, I see, I guess that's why the tests were failing |
My test run didn't go to plan I originally saw this coming from the branch in #272 where the worker and server were running different environments and I think this PR will fix that, but in testing, I have to use them in the same environment with the license file path edited and a new error from fragmenter appears related to the same thing. Testing command
Error
I think this indicates we need to use these decorators here as well. |
I've opened openforcefield/openff-fragmenter#164 to try to fix that; the branch there is |
That branch should be working now, but you'll have to bump |
Blocked in some capacity by a new QCSubmit |
This should now be unblocked by QCSubmit 0.5.0 (re-enables compatibility with legacy QCF) |
Blocked by leeping/forcebalance#285 |
I think this is superseded by #286, @mattwthompson or @jthorton could you confirm? If so (and this is resolved) I'd recommend a BespokeFit 0.2.3 release on Monday, which relaxes pins in the bespokefit conda recipe to allow the use of latest ForceBalance and OFFTK. |
I think we still want the openeye decorators in this PR as well. |
Ahh, apologies. I missed that detail. Please feel free to revert my PR if you'd like to have that all go in at once! |
I'm still having troubles with this - maybe my patch to Fragmenter didn't do what it needed it to do?
|
This has gone stale; if we run into this again it can be revived. |
Description
This PR attempts to fix #271 by checking for an OpenEye license when
oechem
is used and failing out with a descriptive error message. I haven't put the work into testing it in a live run, but the minimal behavior should follow this script:Running (with
openeye-toolkits
installed) and mucking with the license path:I couldn't find other cases in which an
openeye.*
API is actually called, just this bit I don't understand and here, where it's tracked for provenance, it could possibly be useful to also check that it's licensed. That's not related to the original issue so I didn't change that.Todos
Notable points that this PR has either accomplished or will accomplish.
oechem
is calledStatus