The general 'wire-up' to the data issue ...

[ddkapan]

Need to figure out some best practices && then implement them to wire our code to the data

• Best practices, new tools, GoogleCloudPlatform?
• SpatialPtCtPlots.R

[matt-har-vey]

Service account as a way of accessing Google Drive is one alternative to consider.

[ddkapan]

Thanks @matth79 does a service account cost $?

[matt-har-vey]

I believe a service account does not cost money by creating it in a cloud project for which billing is disabled, though I'm not 100% sure of that.

However, now that you got person user accounts working for everyone, sharing around a common credentials file doesn't seem necessary or best. It also was even less easy to understand than the user OAuth token method.

If we end up with automated processes that need to access Drive, service accounts would be the right tool for that.

I did create one and verify it works for our scripts by adding a parameter to drive_auth.

drive_auth(path='service.json')

[matt-har-vey]

Specific cases include

#54 #23

[matt-har-vey]

I tried using symlinks for data dependencies in this commit.

It works, but it made a mess of .gitignore.

If we want the symlinks, maybe it would be good to consider not having lines ending in "input/" in .gitignore except for "original" human-created data like aru2point.csv, latlong.csv, etc. Once you have an ignore ending in a slash, you can't make exceptions underneath it.

A good convention would be that chunk C only ever read input from C/input, and if that input is the output of another chunk B, then the commit that adds the dependent code to C needs to also add a symlink from C/input into B/output, similar to the commit linked above.

If people adhere to that and we don't .gitignore input/, then "git status" will remind them which symlinks they need to add, if they have already created them locally.

[ddkapan]

I actually ignored matt and pushed a .gitignore on a branch and merged the pull request. This is b/c Mark Schulist (elsewhere) confirmed that the symlinks need to be generated especially for each user so synchronizing them with GitHub wasn't going to work anyway. Correct @mschulist? What do you think @matt-har-vey?

[mschulist]

Symlinks need to be generated especially for each user so synchronizing them with GitHub wasn't going to work anyway.

Yes, this is true. We can include a line of code that will (re)create them. We could also just reference the outputs from another script, but that makes it more difficult to see what the inputs are for a given script.

[ddkapan]

• Go over symlink creation code for each occurrence of an /input/ directory in the codebase to finish this