Marvins thoughts on the development

Ludwigm6 commented 3 years ago

What we need:

a directory template for R projects
- data
- docs
- scripts / src
a gitignore template (the standart R gitignore?)
a setup script which loads automatically each time the project gets opened (like start.R in tinyProject)

What we don't need:

custom functions for loading and saving data
custom functions for sourcing scripts
the split of data and main like in tinyProject

What I'm not sure if we need it: A function / variable which stores filepaths (like createEnvi does). This forces the use of paste0 each time you want to use a filepath, but you still have to type in subdirectories manually. If we provide a directory template and work in the project environment, the filepaths should be the same anyway which makes storing obsolete.

gisma commented 3 years ago

Have a look at the readme which describe the basic usage. It is easy to integrate in rstudio the usage of any kind of startup template with the new project -> use template dialogue.

a directory template for R projects

directory template is by default 5 directories (ok that means no template but the function call which supports the full enviMar logic)

data

same as above we need templates

docs

I suggest to integrate a package like rrtools

scripts / src

see above

a gitignore template (the standart R gitignore?)

gitignore is statically generated a template would be fine

a setup script which loads automatically each time the project gets opened (like start.R in tinyProject)

tinyProject is fully implemented but I have changed naming. the setup script is generatet and named setup_project.R as well as a setup_data.R for data pre-processing and control.R for the main control script.

some more templates exist but just the analysis template follows the roxygen2 syntax.

Any default templates are welcome

tnauss commented 3 years ago

Think bigger with DVC

Liebe Runde,

ich hatte ja schon kurz berichtet, dass ich bei der HeFDI-Poster-Session DVC (https://dvc.org/) kennengelernt habe.

Ich habe im Uni-GitLab (https://vhrz1125.hrz.uni-marburg.de) mal rumgespielt und das unten stehende ausprobiert. Das würde unserem Workflow ganz gut entsprechen. Bzgl. der Überlegungen zu einem tpEnvima hätte dies v.a. Auswirkungen auf die Strukturierung von data/.

Zum einen: Wenn wir zentrale Input-Daten irgendwo speichern, also sowas wie z.B. einen Datensatz mit 10 Jahren MODIS NDVI oder COVID-Daten für ganz Deutschland (quasi das, was aktuell auf dem 182er irgendwo rumdümpelt), dann kann man das als zentrales DVC-Repo auf einen Server (z.B. 182 oder den neuen Storage Cluster am HRZ) legen. Mit zentrale Input-Daten meine ich Daten, die wirklich "zentral" und "initial" sind. Also das, was ggf. in mehreren Projekten als Input dient. Wie das geht, steht unten. Dort habe ich mal den Ordner "data/central_registry" dafür angelegt/genutzt. Für das dvc-Tracking im lokalen data Ordner bedeutet dass aber, dass nicht der komplette "data" Ordner unter dvc-Kontrolle gestellt werden kann, was aber sowieso unnötig ist, weil man einen data/tmp Ordner nicht tracken muss.

Zum anderen: Die veränderten Datensätze werden nicht lokal im sog. "cache" verwaltet (Standard ist .dvc/cache) sondern in einem zentralen "Cache-Laufwerk". Das kann wieder z.B. der 182er oder der StorageCluster etc. sein. Wichtig ist, dass alle darauf zugreifen können.

Wenn man jetzt immer schön darauf achtet, dass alle Daten, die für die Ausführung des Codes notwendig sind, mit cvs add ... im Versionsmanagement bleiben, ist alles tutti. Noch besser geht es mit pipelines, in denen man das ganze sehr einfach automatisieren kann. Verändert sich eine der Dateien, die in der Pipeline als Abhängigkeit genannt ist, kann man die Pipeline mit allem drum und dran einfach ausführen.

Wenn Person 1 das so gemacht hat, dann kann Person 2 einfach das Git-Repo von GitHub/GitLab clonen und erhält zunächst mal nur den Code + die DVC-Metadateien. mit "dvc checkout" kommen dann noch die Daten.

Ein paar Use Cases findet Ihr hier: https://dvc.org/doc/use-cases

Hier die Anleitung zum obigen Text:

CENTRAL CACHE DIRECTORY

Create central dvc chace directory (e.g. dvcCentralDataCache)

CENTRAL DVC DATA REGISTRY

Create data repository on accessible drive within an empty and already created GIT repository (e.g. "dvcCentralStorageRegistry") The data will remain on the drive and is not pushed to GITHub/GitLab!

dvc init
dvc add .\data\testdata\
git add 'data\testdata.dvc' 'data\.gitignore'

Local project for data processing (e.g. dvcTest)

Init new Git repository (e.g. https://vhrz1125.hrz.uni-marburg.de/ag-nauss/dvctest) Use envimaR to create folder structure. Folder data/central_registry is for data from central dvc storage registry.

Create dvc on top of git. The following commands are executed within the local copy of dvcTest. dvc init

Configure using central cache directory.

dvc cache dir D:\plygrnd\dvcCentralDataCache\
dvc config cache.shared group
git add .dvc/config
git commit -m "Configure central cache direcotry."

Get data from central storage registry.

cd .\data\central_registry\
dvc import D:\plygrnd\dvcCentralStorageRegistry\ data\testdata\testdata.txt
git add testdata.txt.dvc .gitignore
git commit -m "Add testdata.txt from central data registry."

Add processing folder to dvc and ignore dvc in git.

dvc add .\data\processing\
git add 'data\.gitignore' 'data\processing.dvc'
git commit -m "Compute some statistics and write to output file."

Test by cloning the repo dvcTest to another directory.

Initial cloning will add all metadata (.dvc) but no data. The data comes with dvc checkout. dvc checkout

envima / tpEnvima