Consider using pharmpy to import models

[MikeKSmith]

Pharmpy python package has been created to read and manipulate NONMEM models: https://pharmpy.github.io/latest/index.html.

Rather than having a dependence on RNMImport and the writeNMControlStream function, we could tap into work already done in Pharmpy.

Pros:

• Many features that we may want to use in rspeaksnonmem are already programmed within Pharmpy
• Perl speaks NONMEM (PsN) uses Pharmpy and so it would be a benefit to have both tools referencing the same underlying toolset.
• Pharmpy is likely to be better supported and extended compared to replicating functionality in rspeaksnonmem or RNMImport.

Cons:

• Package would have a dependency on Python and Pharmpy, rather than just R packages.

[billdenney]

I'm definitely in favor of having one great importer. The pain of a requirement of having Python is not to be under-estimated, but I think it's worthwhile.

[andrewhooker]

Hi Bill,

For my own understanding, how do you see the pain that is python dependencies?  What How much extra work is needed when python is involved (for developers and for users)?

Andy

Andrew Hooker, Ph.D. Professor of Pharmacometrics Dept. of Pharmaceutical Biosciences Uppsala University Box 591, 751 24, Uppsala, Sweden Phone: +46 18 471 4355 Mobile: +46 768 000 725 www.farmbio.uu.se/research/researchgroups/pharmacometrics/ On 9 Sep 2020, 17:26 +0200, Bill Denney notifications@github.com, wrote:

I'm definitely in favor of having one great importer. The pain of a requirement of having Python is not to be under-estimated, but I think it's worthwhile. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[billdenney]

@andrewhooker, I see the trouble coming as the fact that the installation and update processes becomes more complex.

For example, instead of running install.packages("rspeaksnonmem"), the user will have to install python (likely only on windows), install pharmpy, confirm that the pharmpy version is compatible with rspeaksnonmem, use different tools to maintain a consistent computing environment (there are tools like packrat that do it for R, but I don't know of ones that will do it for R and python-- other than full Docker containers, VMs or similar).

None of this is insurmountable, but it is more effort. And like I said, I think it is worthwhile.

Also, if there are tools that will help with the consistent environment challenge, I would be happy to learn about them.

[MikeKSmith]

@andrewhooker - I agree with Bill, that the problem is not insurmountable. As Bill says, I think the burden is increased for Windows users, just through installation and management of all of these tools. I expect Docker will help on that front.

The R package {reticulate} works to facilitate getting objects to and from Python, and the ability to embed Python code within rmarkdown ought to make it easier to integrate Pharmpy into R workflows directly, so from the users' perspective it should be essentially transparent. We may not even need to wrap the Pharmapy function calls in R. I'll try to work up a little example workflow to see how it could work.

[billdenney]

I am not a user of reticulate. Does it have the ability to install python libraries? If so, the difficulty could be pretty minimal.

In that case, I could imagine that rspeaksnonmem could detect if the correct version of pharmpy is installed. If it is not, it could prompt the user with a message to install it using an R command (hopefully).

[MikeKSmith]

LMGTFY: https://rstudio.github.io/reticulate/articles/python_packages.html#:~:text=Any%20Python%20package%20you%20install,that%20you%20import%20from%20R.

[billdenney]

A somewhat less common acronym: TYFGTFM (Thank you for googling that for me)

😄

[billdenney]

One more note @andrewhooker for a part of the question that I missed: I think that the extra effort for developers would be comparatively small on balance. There is the moderate to large hurdle that a developer would need familiarity with both R and python, but as noted above, there is the gigantic synergy that all efforts are going to a single parser/generator which will allow much more efficient interoperation and more comprehensive bug fixing, etc.

[MikeKSmith]

Using the documentation provided for pharmpy and integration with R (https://pharmpy.github.io/latest/getting_started.html) I created an additional vignette. I'm really optimistic about using pharmpy with rspeaksnonmem as I think it will shortcut a lot of duplicate code.