Skip to content
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

available via CRAN? #9

Open
nick-youngblut opened this issue Jun 1, 2018 · 12 comments
Open

available via CRAN? #9

nick-youngblut opened this issue Jun 1, 2018 · 12 comments
Labels

Comments

@nick-youngblut
Copy link

As far as I can tell, lme4qtl isn't available from CRAN. Package installation and management with packrat or conda would be facilitated by having lme4qtl available from CRAN. Are you planning (or currently working on) submitting lme4qtl to CRAN?

@variani
Copy link
Owner

variani commented Jun 5, 2018

Hi,

I am currently not planning to submit the package to CRAN, but I might start working on it. Completing documentation is the most time consuming part for me.

I am curious what the exact reason you need lme4qtl at CRAN, apart from things being more convenient to manage. I've checked packrat and it allows installation from GitHub repo.

Best,
Andrey

@nick-youngblut
Copy link
Author

Thanks for letting me know! A CRAN submission has multiple benefits (as noted in Hadley Wickham's R package book). I'm mainly interested in the CRAN submission because my research group uses conda for managing (almost) of of our bioinformatics software (packrat is limited to R). I'm planning on adding a recipe for lme4qtl to bioconda once it's on CRAN. A recipe can be created from a GitHub release tag, but a CRAN url is definitely preferred.

@variani
Copy link
Owner

variani commented Jun 8, 2018

It is good to know about packrat and bioconda. Thanks for sharing!

Definitely, it will take some time to bring lme4qtl to CRAN.

Meanwhile, I can create a temporal solution for you based on GitHub release tags. I previously had the very first release. Is that what you need? I can create a new release based on the latest version of the package (0.1.10).

@variani
Copy link
Owner

variani commented Jun 8, 2018

@nick-youngblut
Copy link
Author

Thanks for creating the release tag! Hopefully, that will pass for conda-forge, at least for now

@variani variani closed this as completed Jun 10, 2018
@variani variani added the cran label Oct 10, 2018
@variani variani reopened this Oct 10, 2018
@variani
Copy link
Owner

variani commented Oct 10, 2018

Current output from devtools::check(cran = TRUE):

Status: 3 WARNINGs, 4 NOTEs

Undocumented code objects:
  ‘VarProp’ ‘assocLmer’ ‘ggimage’ ‘logLikNum’ ‘parseFormula’ ‘relfac’
  ‘varcov’
Undocumented data sets:
  ‘dat40’ ‘kin2’

...

checking dependencies in R code ... NOTE
':::' call which should be '::': ‘lme4:::checkConv’
  See the note in ?`:::` about the use of this operator.
Unexported object imported by a ':::' call: ‘lme4:::updateStart’
  See the note in ?`:::` about the use of this operator.

@viniciushdasilva
Copy link

viniciushdasilva commented Oct 10, 2018

Hi,

I just found a post about the ':::' issue. https://stat.ethz.ch/pipermail/r-devel/2013-August/067210.html

Apparently the solution in the post is not optimum, but can be used with caution (drsimonj/twidlr#16). Another possibility could be a Bioconductor submission. Maybe it would be allowed there.

@lgeistlinger
Copy link

Considering a submission to Bioconductor would definitely be worthwhile.
The repository welcomes packages in the area of genomic high-throughput data analysis such as yours.

https://www.bioconductor.org/about/

It particularly improves on interoperability between packages and automated testing of essential package aspects.

Using the ::: operator is possible (results in a NOTE when running R CMD check), but should be done with care as internal functions might undergo undocumented changes. If possible this should thus be avoided or circumvented by exporting this function in lme4.

That is what the R documentation says:

It is typically a design mistake to use ::: in your code since the corresponding object has probably been kept internal for a good reason. Consider contacting the package maintainer if you feel the need to access the object for anything but mere inspection.

@variani
Copy link
Owner

variani commented Nov 26, 2018

I recently got a few request to submit lme4qtl to CRAN, and appreciate a lot the interest in the package. But I need to say no (at least for now).

I don't feel lme4qtl is mature enough compared to lme4. Particularly, I am concerned about a few issues published so far, #7 and #13. The package was originally designed for particular tasks described in the article and it is good accomplishing these, but fitting other models, e.g. random slopes, can be tricky and the users might misuse the package.

Ideally, I'd like the authors of lme4 to add the lme4qtl features (indeed, they have a relevant branch flexLambda, but it seems to be frozen). Otherwise, I would need to maintain lme4qtl (in parallel to lme4) as well as the lme4 authors do (146 open issues right now). I am not this kind of ninja yet.

Perhaps, the package developers who need lme4qtl might think of using resources like conda, mentioned by the topic starter.

@lgeistlinger
Copy link

The chance for misuse is actually less when having a well-documented version at CRAN / Bioconductor as compared to a typically rudimentary documented version on GitHub.

Nevertheless, even then it's typically out of reach of developers of open-source software how the software is used, with the experimental R paradigm being to enable users to also shoot them in the foot if they desire so.

If you feel that lme4qtl would fit nicely into lme4, then how about opening an issue there / commenting on the relevant branch that you mentioned? That makes lme4 authors aware of your developments and they can accordingly choose whether they can adapt it for their purpose.

@variani
Copy link
Owner

variani commented Nov 28, 2018

Thats is the world of academic software, which we all want to improve and do our best. Having the package at github is not that bad!

@nick-youngblut
Copy link
Author

That is a great article! While hosting academic software on GitHub (or a similar site) can greatly help with software installation, it doesn't do much to directly help with software management. By management, I mean easily installing all of the dependencies required and updating the focal software and the dependencies as needed. Software management tools such as conda or packrat generally work better if the R package is on CRAN (or python package on pypi).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants