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

opentimsr not on CRAN anymore #20

Open
sneumann opened this issue Jun 13, 2023 · 5 comments
Open

opentimsr not on CRAN anymore #20

sneumann opened this issue Jun 13, 2023 · 5 comments

Comments

@sneumann
Copy link

Hi, opentimsr was pulled from CRAN for some non-technical reason,
what changes would be needed to comply with their guidelines ?
Yours, Steffen

@MatteoLacki
Copy link
Collaborator

MatteoLacki commented Jun 13, 2023 via email

@sneumann
Copy link
Author

Thanks for the swift reply, yes, alternatively we could do install_github(),
but something like CRAN or BioC still would make sense. Getting the LICENSE right is important, and there are certainly diplomatic was to get the authors ti fix it if it is just an ommission.
BioC might be an alternative, because @jorainer 's Spectra package has the https://github.com/rformassspectrometry/MsBackendTimsTof.
Yours, Steffen

@MatteoLacki
Copy link
Collaborator

MatteoLacki commented Jun 13, 2023 via email

@michalsta
Copy link
Owner

Hi,

It's deeper than that actually, there was other reason CRAN people mentioned for removal: we use a builtin libzstddec quite deeply in our internals. As R has a package that does zstd, their policy says we should use that: pass back the data to R functions, then get them back to C++ code, then pass back to R internals. That would require us to implement a separate, R-specific code path in libopentims++, which will totally break the architecture of "opentimsr is just R API wrapper for C++ library libopentims++" for no technical reason at all other than "following policy". We tried appealing the removal, but the CRAN people didn't bother to dignify us even with a "no" response.

Seeing now that there are reverse dependencies and actual interest in the package I'll try to "fix" that.

@triston-groff
Copy link

Yes, I will try to get it there after 2 weeks. The license was on the github page, but, as mentioned, its omission was not pointed out by CRAN. Best wishes, Matteo tel. +49 159 01681376 GitHub: MatteoLacki https://github.com/MatteoLacki

On Tue, Jun 13, 2023 at 3:18 PM Steffen Neumann @.> wrote: Thanks for the swift reply, yes, alternatively we could do install_github(), but something like CRAN or BioC still would make sense. Getting the LICENSE right is important, and there are certainly diplomatic was to get the authors ti fix it if it is just an ommission. BioC might be an alternative, because @jorainer https://github.com/jorainer 's Spectra package has the https://github.com/rformassspectrometry/MsBackendTimsTof. Yours, Steffen — Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6H2AFJ6IMQTUQ3YR4OL4LXLBSCFANCNFSM6AAAAAAZEQVMYI . You are receiving this because you commented.Message ID: @.>

Hi,

It's deeper than that actually, there was other reason CRAN people mentioned for removal: we use a builtin libzstddec quite deeply in our internals. As R has a package that does zstd, their policy says we should use that: pass back the data to R functions, then get them back to C++ code, then pass back to R internals. That would require us to implement a separate, R-specific code path in libopentims++, which will totally break the architecture of "opentimsr is just R API wrapper for C++ library libopentims++" for no technical reason at all other than "following policy". We tried appealing the removal, but the CRAN people didn't bother to dignify us even with a "no" response.

Seeing now that there are reverse dependencies and actual interest in the package I'll try to "fix" that.

Hi,

I am wondering if there are any updates on this issue, or an expected timeline?

I tried installing opentimsr from source and devtools, but keep running into compatibility issues with Rtools and build versions of dependencies. Having an install option from a repository like BioC would be extremely useful if CRAN is continuing to be a pain.

I know this has been inconvenient for your team too - I appreciate your efforts!!

Take care,
Triston

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

No branches or pull requests

4 participants