Giving path as object broken

[timcdlucas]

The substitute stuff to make the syntax nicer has broken the ability to give a module path as an object e.g.
path <- '~/MyMod.R'
w <- workflow(path, ....)

now doesn't work because substitute reads this as 'path' not '~\MyMod.R'.

[goldingn]

add a 'local' function?

e.g. occurrence = Local('path/to/file.R'), ...

On Fri, Oct 3, 2014 at 11:32 AM, Tim Lucas notifications@github.com wrote:

The substitute stuff to make the syntax nicer has broken the ability to
give a module path as an object e.g.
path <- '~/MyMod.R'
w <- workflow(path, ....)

now doesn't work because substitute reads this as 'path' not '~\MyMod.R'.

—
Reply to this email directly or view it on GitHub
#42.

Nick Golding
Postdoctoral Researcher
Spatial Ecology & Epidemiology Group
Department of Zoology, University of Oxford
South Parks Road, Oxford OX1 3PS, UK

nick.golding@zoo.ox.ac.uk
+44(0)1865 271137
http://seeg.zoo.ox.ac.uk/

[goldingn]

Hrmm, in retrospect might be tricky to combine this with passing arguments.

Another option is to abandon passing a path, but instead allow user-defined
modules in the global environment (which is already planned I think?)

i.e.:

GetModule('path/to/occmod.R')

w1 <- workflow(occurrence = occmod(arg = 'somearg'), ...)

On Fri, Oct 3, 2014 at 11:57 AM, Nick Golding nick.golding@zoo.ox.ac.uk
wrote:

add a 'local' function?

e.g. occurrence = Local('path/to/file.R'), ...

On Fri, Oct 3, 2014 at 11:32 AM, Tim Lucas notifications@github.com
wrote:

The substitute stuff to make the syntax nicer has broken the ability to
give a module path as an object e.g.
path <- '~/MyMod.R'
w <- workflow(path, ....)

now doesn't work because substitute reads this as 'path' not '~\MyMod.R'.

—
Reply to this email directly or view it on GitHub
#42.

Nick Golding
Postdoctoral Researcher
Spatial Ecology & Epidemiology Group
Department of Zoology, University of Oxford
South Parks Road, Oxford OX1 3PS, UK

nick.golding@zoo.ox.ac.uk
+44(0)1865 271137
http://seeg.zoo.ox.ac.uk/

Nick Golding
Postdoctoral Researcher
Spatial Ecology & Epidemiology Group
Department of Zoology, University of Oxford
South Parks Road, Oxford OX1 3PS, UK

nick.golding@zoo.ox.ac.uk
+44(0)1865 271137
http://seeg.zoo.ox.ac.uk/

[timcdlucas]

Ah I hadn't thought about passing arguments with paths at all. Make it all more tricky.

We had planned to do global env modules. That might be best. Does break the 1 line of code thing though.

[timcdlucas]

Ah I've gotten confused.

workflow(occurence = '~/MyMod.R', ...
DOES work.

Saving the path as an object doesn't work.
path <- '~/MyMod.R'
workflow(occurrenc = path, ...
I don't think this is a common thing at all. However I do need to make a way to pass a URL or path with arguments.

[goldingn]

From watching Bob and others at the workshop, I think the globally-visible
user-defined function is a much more natural pattern than saving to a file
anyway, so best to prioritise that.

That said you need a way of testing local on-disk modules too; so perhaps
the best approach would be to allow the user to define a local repo instead.
I.e.

w1 <- workflow(occurrence = occmod(arg = 'somearg'),
...,
repos = 'path/to/files/')

(where occmod isn't on the main zoon repo)

This may be tricky with naming conflicts if you want some modules from the
main repo and some locally. A simple, but somewhat ugly solution would be:

w1 <- workflow(occurrence = occmod(arg = 'somearg'),
...,
repos_occurrence = 'path/to/files/')

with the default being the main repo...

This would also allow users to clone the entirety of the main repo (or at
least the modules they care about) and work offline, which was a feature
request from the workshop

On Fri, Oct 3, 2014 at 2:01 PM, Tim Lucas notifications@github.com wrote:

Ah I've gotten confused.

workflow(occurence = '~/MyMod.R', ...
DOES work.

Saving the path as an object doesn't work.
path <- '~/MyMod.R'
workflow(occurrenc = path, ...
I don't think this is a common thing at all. However I do need to make a
way to pass a URL or path with arguments.

—
Reply to this email directly or view it on GitHub
#42 (comment).

Nick Golding
Postdoctoral Researcher
Spatial Ecology & Epidemiology Group
Department of Zoology, University of Oxford
South Parks Road, Oxford OX1 3PS, UK

nick.golding@zoo.ox.ac.uk
+44(0)1865 271137
http://seeg.zoo.ox.ac.uk/

[timcdlucas]

I'm still thinking about all this. Just to clarify things, here's a list of where we might want want to get modules from:

An object in the R workspace
A URL
A path to a file on disk
The online, default repo (currently github).

That seems a vaguely sensible order of priority as well. This way, if someone has run GetModules() in the global environment, workflow will find the modules in the global environment and not have to go to the repo.

I'm still thinking through this and it's not directly what I'm working. So just to keep all the info in one place, here is a couple of other musings.

1. We could save modules into a 'zoon' environment when they are downloaded from the repo. This saves on internet calls which are slow. GetModuleList() already saves the list to an environment, this same environment could be used.

2. You can use unnormal characters as a function by quoting them e.g. '+'(1,2). This means an option for syntax for urls and paths is

workflow('~/mylocalModules.R'(para1 = 1, para2 = 'Milvus milvus'),
'www.raw.github.com/me/myrepo/amodule.R'(var = 'AirTemp'),
AGlobalEnvMod(k=3),
AModFromZoonRepo(type='GAM'),
PrintMap)
And finally, doing the same without quotes won't work even with substitute and stuff. And banning tildes doesn't help either.
Which... I guess is messy. But also quite consistant.

[goldingn]

I downvote the last option (paths as operators) as I think it will
completely freak out most users. Also looks ugly to me.

Order of priority sounds OK.

Another option for saving on downloads is a local library of modules, as
per R packages. This would only work in conjunction with a clear and formal
module versioning system though to prevent use of out of date modules.
On 7 Oct 2014 09:39, "Tim Lucas" notifications@github.com wrote:

I'm still thinking about all this. Just to clarify things, here's a list
of where we might want want to get modules from:

An object in the R workspace
A URL
A path to a file on disk
The online, default repo (currently github).

That seems a vaguely sensible order of priority as well. This way, if
someone has run GetModules() in the global environment, workflow will find
the modules in the global environment and not have to go to the repo.

I'm still thinking through this and it's not directly what I'm working. So
just to keep all the info in one place, here is a couple of other musings.

1. We could save modules into a 'zoon' environment when they are
   downloaded from the repo. This saves on internet calls which are slow.
   GetModuleList() already saves the list to an environment, this same
   environment could be used.

2. You can use unnormal characters as a function by quoting them e.g.
   '+'(1,2). This means an option for syntax for urls and paths is

workflow('~/mylocalModules.R'(para1 = 1, para2 = 'Milvus milvus'),
'www.raw.github.com/me/myrepo/amodule.R'(var = 'AirTemp'),
AGlobalEnvMod(k=3),
AModFromZoonRepo(type='GAM'),
PrintMap)
And finally, doing the same without quotes won't work even with substitute
and stuff. And banning tildes doesn't help either.
Which... I guess is messy. But also quite consistant.

—
Reply to this email directly or view it on GitHub
#42 (comment).

[timcdlucas]

As discussed in #44 we are not accepting paths in workflow. Instead use LoadModule()