Becksteinlab / propkatraj

pKa estimates for proteins using an ensemble approach
https://becksteinlab.github.io/propkatraj/
GNU General Public License v2.0
27 stars 7 forks source link

Review/update to work with propka >= 3.3.0 #20

Open orbeckst opened 4 years ago

orbeckst commented 4 years ago

The new propka 3.2.0 release breaks the internal API in parts. To check

IAlibay commented 4 years ago

So I've been playing with getting 3.2 to work (in light of #19 and a possible switch to using AnalysisBase). Unfortunately it looks like quite a few things have changed such that backwards compatibility won't work (one particular case is that using 3.2's propka.input.read_parameter_file doesn't work with NamedStream, and well the fact that it seems that the only way to get things working is to use propka.input).

Since both 3.1 and 3.2 can now be pip installed, I would suggest the following (I'm willing to do the leg work here especially as it would be useful for some work I'm involved with):

1) Set up Travis and add a basic regression test. 2) Switch over to using AnalysisBase (that's easy enough so technically we don't need to do part 1, but having CI in place makes things a lot nicer). 3) Making a final 3.1 release (at this point assuming we mostly rely on things in MDA that are API stable there shouldn't be any future changes). 4) Make the necessary changes in the code to use 3.2 and, if we can't ensure backwards compatibility, make a 3.2-only release.

What do you think?

orbeckst commented 4 years ago

Unfortunately it looks like quite a few things have changed such that backwards compatibility won't work (one particular case is that using 3.2's propka.input.read_parameter_file doesn't work with NamedStream, and well the fact that it seems that the only way to get things working is to use propka.input).

This used to work earlier. Will fix it again in propka...

More later.

orbeckst commented 4 years ago

In general what you say sounds like an excellent plan.

IAlibay commented 4 years ago

@orbeckst So I think we're at step 3 on the proposed schedule timeline. I don't know how you would feel about doing a release now-ish before moving on to propka 3.2 (we would need to drop python < 3.6 support, so it wouldn't be backwards compatible anymore)?

In terms of what is left to do in a final propka 3.1 release, there's #24. However, I doubt it will get fixed upstream in time for MDA 1.0.1. The fix is super trivial (maybe 20 lines?), but I can't seem to be able to find an official list of "PDB standard residues".

I need to get some trajectories analysed with propka 3.2 soon-ish (it's actually been my main motivation for working on this). So I'll probably try to get an initial test implementation done this weekend.

orbeckst commented 4 years ago

Yes, I'll cut a 1.1.0 release #29 with what we have now and then it's onwards and upwards.

You can always do a PR against PROPKA and I can review it there if anything needs fixing in PROPKA (like the ability to use streams) – I am a bit snowed under with millions of things so I am not sure I can get to actual coding anytime soon.

IAlibay commented 4 years ago

You can always do a PR against PROPKA and I can review it there if anything needs fixing in PROPKA (like the ability to use streams) – I am a bit snowed under with millions of things so I am not sure I can get to actual coding anytime soon.

Will do, I think I finally worked out what was causing the issue with streams in 3.2 and it's only ~ 2 typos it seems. There's a deeper issue with the way in which loadOptions works, but I'll just raise it on the Propka side of things.

IAlibay commented 4 years ago

With run.single and read_molecule_file fixed in propka's dev branch switching the current code to use propka 3.2 is quite trivial. I think it's just a case of renaming resNumb to the 3.2 equivalent here: https://github.com/Becksteinlab/propkatraj/blob/20dbca2af33318142f4a4599d4af9eabe9ccc086/propkatraj/propkatraj.py#L206 I can put up a PR that works with the propka dev branch, but we'd have to wait until the next propka version (3.3?) is released for things to move forward again.

orbeckst commented 4 years ago

We can install the propka git in the CI and just move forward. We'll make a 1.1.1 release when we have a corresponding propka release. (It's a patch-level increase because it's a bug-fix from our end.)

orbeckst commented 4 years ago

I think we won't have a propkatraj version that can use proka 3.2.0 so we will have to explicit forbid it in setup.py.

IAlibay commented 1 year ago

As discussed in #36 we should just try a quick PR to see if we can just do >3.3 since I think we fixed this upstream.

IAlibay commented 1 year ago

Mostly for the benefit of @orbeckst

@ianmkenney and I had a chat yesterday and it looks the way errors are generated for things like #10 has changed a lot since propka 3.3. Part of this seems to be due to a change in the underlying code where the issue itself doesn't happen anymore.

Our proposal was to go ahead with a 2.0 release and then do a quick 2.1 release when we have a bit more time to dig into if this yields a behaviour change? It breaks semver a little bit, but it's the easiest I could think of.

orbeckst commented 1 year ago

Thanks for digging into the compatibility. I agree with your plan to get a quick working release out (possibly pinned). This will help with reproducibility. Then we can assess the changes. It's possible that PROPKA simply improved it's own capabilities. For the tests for "bad frames" we might have just taken examples from the wild that failed and then put in the skip.