This repository has been archived by the owner on Sep 9, 2022. It is now read-only.
Possibly break off supplementary data functions to new package? #135
Labels
Comments
|
Sounds like a good idea to me. Is there a reason not to put the code
straight into `doidata`? I've only skimmed the readme, but it sounds like
it would be quite useful for it.
…On Thu, Jan 4, 2018, 6:29 PM Scott Chamberlain ***@***.***> wrote:
@willpearse <https://github.com/willpearse> What do you think of this
idea?
I'm in the process now of reworking fulltext, trying to simplify as much
as possible to make the pkg easier to maintain and less bug prone. As we've
worked on this package, the tooling around searching for and fetching
articles seems like one use case, and getting supplementary files seems
like another. And their downstream uses I imagine are different as well.
Given discussions in https://github.com/ropenscilabs/doidata/ I can
envision fulltext that focuses on articles - a new package that takes the
stuff you've created here and focuses on fetching supplementary files - and
doidata can leverage the new package when users want supplementary data
files w/o all the other tooling here around articles
I realize ft_get_si has S3 methods for ft_data and ft, but *i think* that
would still work fine in another package
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#135>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABLcUlNEwouvZtNhBTHvXZR0glKzu73rks5tHRiVgaJpZM4RTY7H>
.
|
|
cc @noamross My gut feeling is that it'd be good to embrace modularity - so that supplementary data files fetching is a separate package - then Thoughts? |
|
I guess that's Ross' call really, but I would have thought it would be
useful.
I did have this in a separate package before, so I can put it back on its
own. My preference, I think, would be to move the code to
https://github.com/willpearse/natdb and add you, Scott, as a co-author on
that paper (if you're willing, etc.). I think it would give the paper some
extra bang, and would simplify my life in a lot of other ways too.
Let me know what you think. I'm working on the MS draft now so this is
quite nice timing!
…On Fri, Jan 5, 2018, 6:17 PM Scott Chamberlain ***@***.***> wrote:
cc @noamross <https://github.com/noamross>
My gut feeling is that it'd be good to embrace modularity - so that
supplementary data files fetching is a separate package - then doidata
can focus on the quite big task (i think) of making it simple to get data
from lots of different places (zenodo, dryad, github, figshare, and
including journal suppl. files that aren't on dryad/figshare).
Thoughts?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#135 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABLcUs681FPHdkPW0_IderBqKcSQbHKhks5tHmdBgaJpZM4RTY7H>
.
|
|
Hmm, if we broke it out into a new or another pkg (like the one you linked to), i was envisioning a general purpose way to get supplementary materials. It seems like natdb is specific to traits. Or is that wrong? |
|
I was just spit-balling. Such a package already exists (
https://github.com/willpearse/grabr) - when I saw `fulltext` I messaged you
to ask if you would like the code in it.
Would you like to make `grabr` an ROpenSci package, then? If so, I can
merge the changes we made in `fulltext` back into that package, which is
probably easier than starting afresh (see #146). No?
…On Wed, 17 Jan 2018 at 21:42 Scott Chamberlain ***@***.***> wrote:
Hmm, if we broke it out into a new or another pkg (like the one you linked
to), i was envisioning a general purpose way to get supplementary
materials. It seems like natdb is specific to traits. Or is that wrong?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#135 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABLcUsCspl1rZHzD68_Qv0tuV6HNiQllks5tLsvMgaJpZM4RTY7H>
.
|
|
woops, forgot about grabr. get back to you soon on this |
|
No worries and no rush! :D
…On Thu, 18 Jan 2018 at 12:31 Scott Chamberlain ***@***.***> wrote:
woops, forgot about grabr.
get back to you soon on this
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#135 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABLcUuyTGJgQxnlF8bfzhGI8LU-nS4nzks5tL5pPgaJpZM4RTY7H>
.
|
|
Okay, if okay with you, let's move the |
|
Sounds like a plan. Is there a protocol for submitting to ROpenSci? If
there's a link you can direct me to I'll read it and then follow it.
Otherwise I'll just figure it out :D
…On Thu, 18 Jan 2018 at 17:00 Scott Chamberlain ***@***.***> wrote:
Okay, if okay with you, let's move the ft_get_si functionality into grabr
- and would you be okay submitting to ropensci? Noam had a good suggested
pkg name suppdata (pkg name totally up to you though)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#135 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABLcUkiUvk90NBqWnRQeu6iUFRhtzUHsks5tL9swgaJpZM4RTY7H>
.
|
|
cool. we now have a formal review system https://github.com/ropensci/onboarding/ where we get 1 to 2 reviewers - I can make sure it doesn't take too long since it was essentially code that was in an ropensci pkg already - |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
@willpearse What do you think of this idea?
I'm in the process now of reworking
fulltext, trying to simplify as much as possible to make the pkg easier to maintain and less bug prone. As we've worked on this package, the tooling around searching for and fetching articles seems like one use case, and getting supplementary files seems like another. And their downstream uses I imagine are different as well.Given discussions in https://github.com/ropenscilabs/doidata/ I can envision
fulltextthat focuses on articles - a new package that takes the stuff you've created here and focuses on fetching supplementary files - and doidata can leverage the new package when users want supplementary data files w/o all the other tooling here around articlesI realize
ft_get_sihas S3 methods forft_dataandft, but i think that would still work fine in another packageThe text was updated successfully, but these errors were encountered: