search

RConsortium / submissions-pilot3-utilities

A simple R package used to test submission process to the FDA
GNU General Public License v3.0
7 stars 1 forks source link

can't load `pilot3` after installation #9

Closed kaz462 closed 1 year ago

kaz462 commented 1 year ago

have trouble loading pilot3 after installation, it gets stuck on library(pilot3) and then freezes

elong0527 commented 1 year ago

The PR #10 should address the issue.

Not sure why you want to separate the pilot3 into 2 separate repos. Are you planning to submit this package to CRAN?

Having a submission package depends on an R package on github is not a good practice.

cc: @lengning, @nanxstats

nanxstats commented 1 year ago

Not sure if I understand the specific problem or context here... 😅 The overarching goal is to make the eCTD project self-contained and avoid the need to connect to any non-CRAN, remote dependencies hosted on platforms like GitHub.

If there are one or more proprietary R packages, we can pack them into a single text file into the eCTD project under module 5 using pkglite, in the order of installation.

Perhaps some historical context would be useful. Besides using pkglite for packing the proprietary package (s), submission pilot 1 also used renv for package development but did not use it in the reviewer workflow for simplicity. Submission pilot 2 pushed this further by using renv to restore some running environments in the reviewer flow. See the Appendix sections in ADRG of pilot 1 and ADRG of pilot 2 for details.

kaz462 commented 1 year ago

Thanks @elong0527 @nanxstats for addressing this issue and providing some background information :)

Here are some meeting notes from @laxamanaj after a call with FDA today:

Question to FDA: As mentioned in past R Consortium WG meeting : https://rconsortium.github.io/submissions-wg/minutes/2023-04-07/ , Pilot 3 is working in 3 repos, where the Proprietary package is its own repo and is installed using {pak} or {remotes} instead of using {pkglite}'s text file approach. Are you ok if we don't use {pkglite} or would you suggest we use it as Pilot 1 and Pilot 2 did?

Response : Yes, they are ok NOT to use {pkglite} as our current approach suits more of the standard ways of working in the R environment. That is installing any package using a more standard R approach like : install.packages(), remotes::install_github(), pak::pkg_install(), instead of the {pkglite} approach.

cc: @bms63 @robertdevine @DeclanHodges