[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

dotdrop/docs/usage.md

Line 304 in 7ee84a9

* `DOTDROP_WORKDIR`: overwrite the `workdir` defined in the config

but DOTDROP_WORKDIR is not checked in file

dotdrop/dotdrop/options.py

Line 28 in 7ee84a9

ENV_DEBUG = 'DOTDROP_DEBUG'

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.