incorporate SpaDES.project::getModule() into downloadModule()

[achubaty]

Pull this code into downloadModule():

https://github.com/PredictiveEcology/SpaDES.project/blob/transition/R/getModule.R

[achubaty]

from our zulip discussion:

Eliot McIntire: I am thinking that this would be better left in SpaDES.install and get SpaDES.install on CRAN... installing modules is much more successful when there are no packages loaded. I know that downloading a module doesn't require any packages... but immediately after downloading a module is a good time to get packages installed. If SpaDES.core had to be loaded before downloading a module, then user could get into an endless loop. THe point of SpaDES.install is to have almost no dependencies so that installations can be seamless.

Alex Chubaty: That’s a good point.I do still want the functionality to get sub modules otherwise our modules repo becomes less functional.

I don’t want to maintain two versions… thoughts? (I assume we are ruling out adding install as dep of core)

Eliot McIntire: Why do we need sub-modules in SpaDES.core, if it is never SpaDES.core's job to get modules?

Eliot McIntire: I feel like it isn't SpaDES.core's job to ever get modules. We could add SpaDES.install to SpaDES as a way to wrap it into the ecosystem.

Eliot McIntire:
modules repo

Eliot McIntire: I feel like this is a very low priority at the moment. Now that we can just specify the true origin on GitHub ... achubaty/LandWeb or PredictiveEcology/LandR, we don't really need to maintain the SpaDES-modules repo. I understand that we will eventually want something (a la CRAN), but my hunch is there are design things that we haven't really dealt with yet for it to be as useful as CRAN

Alex Chubaty: not using module repo is an option -- and one I'm ok with because that's not how we are using it. (but we are also git-savvy developers)

it was part of SpaDES.core initially, but if this functionality goes elsewhere, maybe that's ok.

if we deprecate the modules repo, need to update docs etc., but otherwise i'm open to this change.

Eliot McIntire: I feel like we can just leave the SpaDES-modules repo as is, and just proceed forward with direct links to each module's repository as we progress. i.e., "no-cost option A". I feel like we may find a much simpler "SpaDES-modules" repository approach that is actually just a set of pointers to original GitHub repositories, rather than actual git sub-modules... way lighter to maintain

Alex Chubaty: yup that can work. i think getModule() meets the needs of someone who isn't git-aware, so it would be a drop in replacement for downloadModule(). does this mean downloadData() should be revamped/moved too?

Alex Chubaty: as far as maintaining a list of modules -- we sort of have that on the wiki

Eliot McIntire: I feel like downloadData is an anachronism now. i.e., we don't actually bundle data with a module as data generally exist outside of SpaDES module land.

Alex Chubaty: yes re: downloadData

Eliot McIntire: For the "list of modules", it (a wiki or whatever it evolves into) would have to have some structure that allows some algorithmic downloading via the "list of modules"

[achubaty]

Further discussion from Oct 27:

• don't want to maintain 2 versions. If we get SpaDES.install on CRAN we can simply import the function in core. Otherwise, would need to keep copy. (Eliot thinks we should remove downloadModule functionality completely from core but Alex wants to keep it so non-GitHub, non-drat, non-universe users have a way of getting modules.)
• note: getting modules is different from installing packages deps, the latter of which we agree should remain external to core
• deprecate downloadData