[bug] env-var. DOTDROP_WORKDIR does not work

[ShoHoukyo]

Dotdrop version (and git commit if run from source): v1.14.0 Using dotdrop: pipx install dotdrop

Describe the bug

DOTDROP_WORKDIR: overwrite the workdir defined in the config https://github.com/deadc0de6/dotdrop/blob/7ee84a92ecdce09eec4fcafe47330e6788aa1ace/docs/usage.md#L304

but DOTDROP_WORKDIR is not checked in file https://github.com/deadc0de6/dotdrop/blob/7ee84a92ecdce09eec4fcafe47330e6788aa1ace/dotdrop/options.py#L28

as of dotdrop v1.14.0 (installed by pipx install dotdrop), env-var. DOTDROP_WORKDIR does not work for command dotdrop install

Expected behavior

DOTDROP_WORKDIR used to determine final install locations (in my case, no link, just generate files)

Additional information

The relevant part of the config file

{
    "config": {
        "backup": true,
        "banner": true,
        "create": true,
        "dotpath": "template_files",
        "ignoreempty": false,
        "keepdot": false,
        "key_prefix": true,
        "link_dotfile_default": "nolink",
        "longkey": true,
        "showdiff": false
    },
    "dotfiles": {
        "common_diff.toml": {
            "dst": "common/diff.toml",
            "src": "common/diff.toml",
            "template": true
        },
        "common_firewall": {
            "dst": "common/firewall",
            "src": "common/firewall",
            "template": true
        },
        "common_same.cfg": {
            "dst": "common/same.cfg",
            "src": "common/same.cfg",
            "template": true
        },
        "common_tos.txt": {
            "dst": "common/tos.txt",
            "src": "common/tos.txt",
            "template": true
        },
        "dir1only": {
            "dst": "dir1only",
            "src": "dir1only",
            "template": false
        },
        "dir2only": {
            "dst": "dir2only",
            "src": "dir2only",
            "template": false
        }
    },
    "profiles": {
        "profile1": {
            "dotfiles": [
                "dir1only",
                "common_diff.toml",
                "common_firewall",
                "common_same.cfg",
                "common_tos.txt"
            ],
            "variables": {
                "var_JEC_P_2d10123": "JEC",
            }
        },
        "profile2": {
            "dotfiles": [
                "dir2only",
                "common_diff.toml",
                "common_firewall",
                "common_same.cfg",
                "common_tos.txt"
            ],
            "variables": {
                "var_JEC_P_2d10123": "P",
            }
        }
    }
}

(json is valid yaml)

[deadc0de6]

@ShoHoukyo DOTDROP_WORKDIR as far as I can tell works as expected, it is used in all tests and I just tested it. Can you please provide me with a use-case where it is not working for you?

The workdir is not used to determine final install locations but for the temporary destination of templated symlinked files as described here and here.

Path to the directory where templates are installed before being symlinked when using link:absolute|relative|link_children

It may be a misunderstanding on the workdir usage. The final destination of any dotfile is defined by its entry in the config file, as for example:

dotfiles:
  f_abc:
    dst: ~/.abc
    src: abc

The destination of the f_abc dotfile is ~/.abc.

[ShoHoukyo]

Thanks! It's a misunderstanding.

I understand this is not intended use of dotdrop, but is there any way to output to 2 different dirs based on profile (like below)? Example based on above config.yaml:

# DOTDROP_PROFILE=profile1 dotdrop install
outputs to
profile1/common/diff.toml
...

# DOTDROP_PROFILE=profile2 dotdrop install
outputs to
profile2/common/diff.toml
...

[deadc0de6]

What you are trying to do is absolutely doable with dotdrop and there are multiple ways to achieve it:

• by using two entries pointing to the same file

  dotfiles:
  f_abc_profile1:
  dst: ~/profile1/common/diff.toml
  src: abc
  f_abc_profile2:
  dst: ~/profile2/common/diff.toml
  src: abc
  profiles:
  profile1:
  dotfiles:
  - f_abc_profile1
  profile2:
  dotfiles:
  - f_abc_profile2

• by using variables

  variables:
  basedst: "profile1"
  dotfiles:
  f_abc:
  dst: "~/{{@@ basedst @@}}/common/diff.toml"
  src: abc
  profiles:
  profile1:
  dotfiles:
  - f_abc
  profile2:
  dotfiles:
  - f_abc
  variables:
    basedst: "profile2"

• by using the profile name directly (when it somehow matches the expected file destination)

  dotfiles:
  f_abc:
  dst: "~/{{@@ profile @@}}/common/diff.toml"
  src: abc
  profiles:
  profile1:
  dotfiles:
  - f_abc
  profile2:
  dotfiles:
  - f_abc

• you could even use exported env variables defined on the host itself (like export MY_DST_FOR_THIS_PROFILE="...")

  dotfiles:
  f_abc:
  dst: "~/{{@@ env['MY_DST_FOR_THIS_PROFILE'] @@}}/common/diff.toml"
  src: abc
  profiles:
  profile1:
  dotfiles:
  - f_abc
  profile2:
  dotfiles:
  - f_abc

• or use something defined through a file on the host for example

  dynvariables:
  basedst: "cat /tmp/somefile | grep basedst= | sed 's/basedst=//g'"
  dotfiles:
  f_abc:
  dst: "~/{{@@ basedst @@}}/common/diff.toml"
  src: abc
  profiles:
  profile1:
  dotfiles:
  - f_abc
  profile2:
  dotfiles:
  - f_abc

And of course any combinations of the above. It all depends on your exact needs but that definitely enters dotdrop goals.