dpastoor
commented
1 year ago I think the sane default would be to check if there was a well-known env variable set that we could then also decorate with some known things we could establish. What i mean by that is to push the value of the env variable through a templating engine that has some values we could use - here is the spec I would propose we look for two environment variables:
simple case
DVS_INIT_ROOT - if set, the pattern used would be filepath.Join(dvsInitRoot, dirname(proj))
so given a project named proj123 and a DVS_INIT_ROOT=/data/dvs - the resulting storage directory would be /data/dvs/proj123.
in addition, this should only be set if the directory does not exist, and should fail with a "dir already exists, please explicitly define the storage directory style error".
full control case
if DVS_INIT_ROOT_TMPL is defined, it takes precedence over DVS_INIT_ROOT (its "more specific") - and inside the TMPL, we would expand the following variables
- .User - the username
- .Dir - directory of the project
- .Pwd - working directory where the command is run from
- .Date - date specified as YYYY-MM-DD
- .Year - YYYY
- .UnixTime - unix timestamp with second level fidelity
so for example given
DVS_INIT_ROOT_TMPL="/data/dvs/{{.User}}/{{.Dir}}" --> /data/dvs/dpastoor/proj123
We would not add the project dir or anything to this definition, as it would be expected for the person to fully control this
or
DVS_INIT_ROOT_TMPL="/data/dvs/{{.Year}}/{{.Dir}}" --> /data/dvs/2023/proj123
@martinlardi mentioned this might be helpful to have since we have a pretty defined /data/ folder -- this would probably need to be a configuration per-user or per-install