[Help] Managing public and private dotfiles with files with the same name but different content, and not both have some files

[gusbemacbe]

Share content across dotfiles teaches how to manege different dotfiles, but my case is different. One is private and another is public.

I also read Profile block that explained how to manage two private and public profiles, but I can not store sensitive info.

For example, both private and private dotfiles have a same file .env.private but a different content. The public dotfiles's .env.private contains fake password and IP address, while the private dotfile's contains true password and IP address. When to use dotdrop to install, the public dotfiles's .env.private file needs to be replaced or overwritten by the private dotfiles's .env.private file to the local machine.

Also, the private dotfiles contain additional files that are not present in the public dotfiles due to sensitive information. For example, the private dotfiles contain few directories and files like .firestorm and .mozilla, etc. I need to copy it to my computer when I use the public dotfiles.

Is it possible to combine and merge these two dotfiles, using one or two (config-user.yaml and config-root.yaml) from a dotfiles repository (preferably from the public repository), to copy the true files and the missing folders from the private dotfiles?

Is it possible to set multiple profiles for --profile? For example:

dotdrop install --cfg "config-root.yaml" --profile "minimal-dotfiles debian i3"

[gusbemacbe]

I was going to test it, but I received the error, because my private and public dotfiles are on my portable SSD. Here is the error message:

dotdrop import ~/.aspell.en_GB.pws ~/.aspell.en.pws
Traceback (most recent call last):
  File "/home/gusbemacbe/.local/share/pypoetry/venv/bin/dotdrop", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/home/gusbemacbe/.local/share/pypoetry/venv/lib/python3.12/site-packages/dotdrop/__init__.py", line 13, in main
    if dotdrop.dotdrop.main():
       ^^^^^^^^^^^^^^^^^^^^^^
  File "/home/gusbemacbe/.local/share/pypoetry/venv/lib/python3.12/site-packages/dotdrop/dotdrop.py", line 936, in main
    opts = Options()
           ^^^^^^^^^
  File "/home/gusbemacbe/.local/share/pypoetry/venv/lib/python3.12/site-packages/dotdrop/options.py", line 162, in __init__
    self.confpath = os.path.abspath(self.confpath)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen posixpath>", line 410, in abspath
TypeError: expected str, bytes or os.PathLike object, not NoneType

[gusbemacbe]

I understood now.

It is because I did not create a config_user.yaml. If I create an empty file, it also will fail, therefore, I have to copy the small code part:

config:
  backup: true
  banner: false
  create: true
  dotpath: dotfiles
  ignoreempty: false
  keepdot: true
  longkey: false
  showdiff: false
  workdir: ~/.config/dotdrop
dotfiles:
profiles:

I think dotdrop should create automatically a configuration file when importing.

[gusbemacbe]

The option --profile "minimal-dotfiles debian i3" is totally impossible and it can not detect different profiles instead of one profile when installing because it interprets the value as one profile instead of three profiles.

[deadc0de6]

Hello,
let me try to split your questions/requests in several parts, hopefully these answer your questions.

(1) Getting dotdrop to auto-generate a default config file when it does not exist

I understand your point and that would not be very difficult to implement. But mostly I think it might be misleading since the config file contains more than just a list of dotfiles (like the dotpath and the rest) which would create a complex situation in case someone mistype his config file and ends up with a new config file as well as imported files in his dotpath.
However I could create a command that would create a default config to avoid users to have to download manually the config file from dotdrop repo.

(2) error TypeError: expected str, bytes or os.PathLike object, not NoneType

I agree that dotdrop should output a cleaner error when that occurs. I'm guessing somehow your disk wasn't available at that time? Can you give me more info on what happened at that point?

(3) use multiple profiles

Doing something like --profile "minimal-dotfiles debian i3" is not possible in dotdrop however you could easily solve this by having a profile including the other ones in your config. That would look a bit like this:

profiles:
  minimal-dotfiles:
    dotfiles:
      - f_file1
      - f_file2
 debian:
    dotfiles:
      - f_file3
      - f_file4
  i3:
    dotfiles:
      - f_file5
      - f_file6
 wrapper:
  include:
    - minimal-dotfiles
    - debian
    - i3

In above examples, calling dotdrop with --profile wrapper would include the three profiles minimal-dotfiles, debian and i3.

(4) Have private and public dotfiles with different content

This can be achieved using variables. The public config file would have fake variables while the private one will contain the effective value. The dotfile in question could look something like this:

password1: {{@@ password1 @@}}
password2: {{@@ password2 @@}}

while the public config is

variables:
  password1: fake1
  password2: fake2

and the private config is

variables:
  password1: a-real-password
  password2: another-real-password

Or, if you don't want to store those secrets in the config, you could use environment variables as for example here.

(5) Have private and public dotfiles with different files

My understanding is that you want to handle secrets in your dotfiles, didn't any of the solution presented here work for you?

[gusbemacbe]

2. Both on the portable and internal SSDs, within an empty dotfiles folder, I ran the simple command dotdrop import ~/.blabla and it gave this same error. Also, both on these drives, if I created an empty config_user.yml, I ran the command dotdrop --import --cfg "config_user.yml" and received the same error. Do you still need the debug log with -V?

3. I do not think it will solve desire of the user interested in my dotfiles because they will choose any one or how many available profiles they want. My configuration files also will have arch, gnome, kde, sway, etc. Maybe I will suggest the interested users to use Bash or another programming language command line for:

   # List the profiles, then choose one or more you wish to install
   dotdrop -c "config_user.yml" profiles -bG
   for profile in profile1 profile2 profile3; do dotdrop install -c "config_user.yml" --profile "$profile"; done

4. Let me understand... You are suggesting to insert the similar first code block in both dotfiles' .env.private file:

   GITHUB_PERSONAL_ACCESSS_TOKEN="{{@@ password1 @@}}"
   GITLAB_PERSONAL_ACCESS_TOKEN="{{@@ password2 @@}}"
   SSH_USER="{{@@ user1 @@}}"
   SSH_IP_ADDRESS="{{@@ ip1 @@}}"

   Then the private config_user.yml contains:

   variables:
     password1: true_value
     password2: true_value
     user1: true_value
     ip1: true_value

   And the public:

   variables:
     password1: false_value
     password2: false_value
     user1: false_value
     ip1: false_value

   Is it all correct?

5. No, I mean the same files but with different content (content = text), as you have already explained in the item. I mean that the private dotfiles have some files or folders that the public dotfiles do not have. I was asking if it is possible to call the private dotfiles from the public dotfiles via dotdrop command, to install the missing files and folders to the local machine.

[deadc0de6]

I'm adding a new command (gencfg) that would generate a clean config file (see #446). PR #445 should fix the errors you see in (2), at least be more explicit on what is missing.

Regarding calling dotdrop with multiple profiles (3), it is indeed advised to use some bash fu to do what you want to do as those profiles are independant and thus dotdrop should be called for each of them. Your example should work.

For (4), yes that's exactly what I'm suggesting, wouldn't that work for you?

It's however still not clear to me the use-case for (5). In the end if you share (git, etc) your dotpath but still want some of its content to be private, then you should have them encrypted. If however you want dotdrop to use them if present and not if absent, then you might want to look into something like

• import_config - selectively import a specific config on private that would include specific dotfiles
• use jinja templating features directly (see https://jinja.palletsprojects.com/en/2.11.x/templates/?highlight=delimiter) - complete files in specific use-cases with if-else case
• profile import - import a private profile if specific files are here
• use actions maybe

You could also use bare profiles, for example

• profile forall has files common to your public and private dotfiles
• profile private contains only your private files
• profile public contains only your public files
• profile private includes forall
• profile public includes forall

Then you'd selectively use profile private or public depending on which content you want to deploy.

[deadc0de6]

BTW regarding (4), if you plan on publishing in a public repo your config file, it might not be wise to have your creds in your config file. For that use-case you should use environment variables (see env variables).

[gusbemacbe]

I'm adding a new command (gencfg) that would generate a clean config file (see #446). PR #445 should fix the errors you see in (2), at least be more explicit on what is missing.

I am going to update dotdrop, and test it.

For (4), yes that's exactly what I'm suggesting, wouldn't that work for you?

I was going to test and see if it works or not, but you have just said in your last comment. I am going to test it.

But, by chance, it is safe to store a env.private file or variables on the config.yml encrypted with GnuPG with a password on a public repository?

According to some hacking and GnuPG experts, a GnuPG encrypted file password can be brute-forced.

What GnuPG files should I store and should I not store?

Then you'd selectively use profile private or public depending on which content you want to deploy.

I think I would firstly pick public and then private to overwrite the existing files, or to copy the missing contents.

[gusbemacbe]

I installed, running the command pip install git+https://github.com/deadc0de6/dotdrop.git@gencfg-command and created an empty folder. Within this folder, I used the terminal and ran these commands:

[deadc0de6]

But, by chance, it is safe to store a env.private file or variables on the config.yml encrypted with GnuPG with a password on a public repository?

I would suggest using asymmetric key cryptography but this is beyond dotdrop.

Regarding your test on branch gencfg-command, there are actually two branches:

• gencfg-command - adds a gencfg command
• fail-on-non-existing-config - properly handles missing config file

I think you wanted to use fail-on-non-existing-config. In order to test a branch/PR, you can follow this doc.

[deadc0de6]

@gusbemacbe FYI I merged the two above PRs and if you use the master branch you should get the fixes.

[gusbemacbe]

Despite your suggestion on that documentation, I prefer installing from git via pip.

1. I ran pip uninstall dotdrop and pip3 install git+https://github.com/deadc0de6/dotdrop.git@master.
2. I ran mkdir -p dotfiles-empty-with{,out}-cfg to create two test folders – dotfiles-empty-without-cfg and dotfiles-empty-with-cfg.
3. I tested the command dotdrop import ~/.env ~/.env.private and received the error "[ERR] yaml error: no config file found". I checked the help and saw to have to use the option gencfg. Then I ran dotdrop gencfg > "config_user.yml". It worked only with gencfg before importing.
4. Then I had to uninstall the package to test with the fail-on-non-existing-config branch from the which I reinstalled via pip.
5. The same error in the item 3.

What do you think about it?

[gusbemacbe]

I performed a test.

1. I create two dotfiles folders – private and public.

2. On the public dotfiles folder, I created the folders containing a cities.txt:

   • .test-01
   • .test-02
   • .test-03

3. The .test-03's cities.txt file contains the text:

   - Aparecida, São Paulo, Brazil
   - Paris, Île-de-France, France
   

4. On the private dotfiles folder, I created the folders containing a cities.txt:

   • .test-03
   • .test-04
   • .test-05

5. The private dotfiles folder's .test-03's cities.txt file contains the text:

   - Aparecida, São Paulo, Brazil
   - Castelnuovoo di Garfagnana, Tuscany, Italy
   - Lucca, Tuscany, Italy
   - Paris, Île-de-France, France
   

6. I generated for both dotfiles folders:

   • public:

     config:
       backup: true
       banner: false
       create: true
       dotpath: dotfiles
       ignoreempty: false
       import_configs:
         - ../dotfiles-private/confg_user.yml
       keepdot: true
       link_dotfile_default: nolink
       link_on_import: link
       longkey: true
     dotfiles:
       d_test-01:
         src: .test-01
         dst: ~/.test-01
       d_test-02:
         src: .test-02
         dst: ~/.test-02
     profiles:
       tests:
         dotfiles:
         - d_test-01
         - d_test-02
         - d_test-03
         include:
         - general

   • private:

     config:
       backup: true
       banner: false
       create: true
       dotpath: dotfiles
       keepdot: true
       link_dotfile_default: nolink
       link_on_import: nolink
       longkey: true
     dotfiles:
       d_test-03:
         src: .test-03
         dst: ~/.test-03
       d_test-04:
         src: .test-04
         dst: ~/.test-04
       d_test-05:
         src: .test-05
         dst: ~/.test-05
     profiles:
       general:
         dotfiles:
         - d_test-03
         - d_test-04
         - d_test-05

7. I have run the command dotdrop install -td -c "confg_user.yml" -p "tests" on the public dotfiles folder. I have checked the tmp folder, verified and seen it has worked. The private dotfiles' .test-03 folder's cities.txt successfully has overwritten that of the public dotfiles.

But since that the interested user will want to install with that same command to install the public dotfiles, we will receive the error, saying that the private dotfiles folder is not found. I have tested, renaming ../dotfiles-private/confg_user.yml to ../dotfiles-private-unexisting/confg_user.yml and received the error with the same command: [ERR] yaml error: bad path ~/Tests/Dotdrop/dotfiles-private-unexisting/confg_user.yml. I think that it is because dotdrop install does not have the option to ignore the missing content (-z or --ignore-missing). They have to install my public dotfiles without dotdrop complaining about the missing private dotfiles folder.

[gusbemacbe]

If you want to test with my compressed files, you can receive it here:

dotdrop-test.zip

[gusbemacbe]

BTW regarding (4), if you plan on publishing in a public repo your config file, it might not be wise to have your creds in your config file. For that use-case you should use environment variables (see env variables).

I also have tested it and haven't liked it because I want to share the files with some environment variables as examples for the learners of the tutorials like SSH and VPS. I think that the import configuration is the best solution with false and true variables on the DotDrop configuration file because it can overwrite the existing files like I have done.

[deadc0de6]

Despite your suggestion on that documentation, I prefer installing from git via pip.

1. I ran `pip uninstall dotdrop` and `pip3 install git+https://github.com/deadc0de6/dotdrop.git@master`.

2. I ran `mkdir -p dotfiles-empty-with{,out}-cfg` to create two test folders – `dotfiles-empty-without-cfg` and `dotfiles-empty-with-cfg`.

3. I tested the command `dotdrop import ~/.env ~/.env.private` and received the error "[ERR] yaml error: no config file found". I checked the help and saw to have to use the option `gencfg`. Then I ran `dotdrop gencfg > "config_user.yml"`. It worked only with `gencfg` before importing.

4. Then I had to uninstall the package to test with the `fail-on-non-existing-config` branch from the which I reinstalled via `pip`.

5. The same error in the item 3.

What do you think about it?

Yes that's what I discussed in point (1) above. Dotdrop will warn you that you are missing a config file and now provides a command (gencfg) to automatically create a clean new one for you.

[deadc0de6]

But since that the interested user will want to install with that same command to install the public dotfiles, we will receive the error, saying that the private dotfiles folder is not found. I have tested, renaming ../dotfiles-private/confg_user.yml to ../dotfiles-private-unexisting/confg_user.yml and received the error with the same command: [ERR] yaml error: bad path ~/Tests/Dotdrop/dotfiles-private-unexisting/confg_user.yml. I think that it is because dotdrop install does not have the option to ignore the missing content (-z or --ignore-missing). They have to install my public dotfiles without dotdrop complaining about the missing private dotfiles folder.

You might want to read the doc on import_configs here. You have the option to set a imported config as optional (by appending :optional):

import_configs:
- other-config.yaml:optional

ignore-missing is not what you think it is, see the related doc.

[gusbemacbe]

You might want to read the doc on import_configs here. You have the option to set a imported config as optional (by appending :optional):

import_configs:
- other-config.yaml:optional

I have tested it with the addition of :optional, and it did not allow the private dotfiles folder's .test-03 folder's cities.txt file to overwrite the the public dotfiles folder's .test-03 folder's cities.txt file.

[gusbemacbe]

I have investigated, testing without optional and using old versions of dotdrop, and it did not allow to overwrite the file even if with -f or --force and showdiff.

I reviewed the old dotdrop configuration file of the public dotfiles and I understood that I did not insert this code in the old file:

  d_test-03:
    src: .test-03
    dst: ~/.test-03

If I did not insert this code, with or without optional, the private dotfiles folder's .test-03 folder's cities.txt file would be copied, but if I inserted this code in both public and private dotfiles' dotdrop configuration file, with and without optional, the latter file would not be copied to overwrite the first file.

I provide the latest compressed file for you to analyse and test: dotdrop-test-02.zip

[gusbemacbe]

I also tested with actions, using pre to use chmod for a script file, and post to run the script file to copy, and it did not work either.

[deadc0de6]

Here's what I tested:

• installing the private config

$ dotdrop install --cfg dotfiles-private/config_user.yml -p general
$ cat .cities
CITY="Rome"
$ cat .test-03/cities.md
- Aparecida, São Paulo, Brazil
- Castelnuovo di Garfagnanna, Tuscany, Italy
- Lucca, Tuscany, Italy
- Paris, Île-de-France, France

This is working as expected

• installing the public config with a non-existing private config (thus not importing the private config)

$ dotdrop install --cfg dotfiles-public/config_user.yml -p tests
[WARN] bad path dotfiles-private/xxxconfig_user.yml
$ cat .cities
CITY="Paris"
$ cat .test-03/cities.md
- Aparecida, São Paulo, Brazil
- Paris, Île-de-France, France

This is working as expected

• and finally installing the public config with an existing private config file, thus expecting everything in the public config that exists in the private one to be overwritten:

$ dotdrop install --cfg dotfiles-public/config_user.yml -p tests
$ cat .cities
CITY="Rome"
$ cat .test-03/cities.md
- Aparecida, São Paulo, Brazil
- Paris, Île-de-France, France

The .cities contains what the private config provides but indeed .test-03/cities.md is not correct.

There's a quick fix: You need to have an unique dotfile name in your private config that targets the same file as the one in the public config, for example (private config):

  d_test-03-overwrite:
    src: .test-03
    dst: /tmp/xxx/.test-03
...
profiles:
  general:
    dotfiles:
    - d_test-03-overwrite
    - d_test-04
    - d_test-05
    - f_cities

The issues comes from the fact that when merging imported dotfiles, if there's a name conflict (for example d_test-03 string being defined in both the main and the imported config), the main config will take precedence.

[deadc0de6]

I'm working on a fix in #449

[deadc0de6]

Actually dotdrop is on purpose giving priority on the importing config's dotfiles. This means imported config's dotfiles will not overwrite importing config's dotfiles. I don't want to modify the way dotdrop works now as people might depend on that behavior.

I will however improve the documentation to clearly mention that. Regarding your issue, having a different dotfile name but targeting the same file (as shown above) would solve your issue.

Sorry for the misunderstanding.

[deadc0de6]

Here's the part of the documentation I'm adding through #450

In case of a name clash (same name in importing and imported configs), the importing config will take precedence except for the variables and dynvariables (see variables and CONTRIBUTING doc).

[gusbemacbe]

I will however improve the documentation to clearly mention that. Regarding your issue, having a different dotfile name but targeting the same file (as shown above) would solve your issue.

If I want to import, but renaming the dotfile keyname? I listed the options for import, and it does not have an option to rename. It is possible only to modify manually on the dotdrop configuration file.

dotdrop import --cfg dotfiles-private/config_user.yml -p tests ~/.test-03

I would run this similar command but a new option:

dotdrop import --cfg dotfiles-private/config_user.yml -p tests --name "d_test-03-overwrite" ~/.test-03

[gusbemacbe]

While you do not answer yet, I will reconsider your branch import_config-dotfiles-precedence that you did not delete. I will install from the specific branch via pip or poetry. I will use it temporarily.

[deadc0de6]

Can you give a try to the user-key-on-import branch? It provides the ability to specify the key you want to use with -K --dkey

[gusbemacbe]

I have just given a try and it worked perfectly! Then people who might depend on that original behaviour will not have problem with the new user-key-on-import feature, unlike the import_config-dotfiles-precedence feature!

I will use both import_config-dotfiles-precedence and user-key-on-import branches.

[deadc0de6]

Awesome, I've merged the branch into master and will release a new version of dotdrop in the coming week.
Thanks for your help on this. I'm closing this issue but if you need anything more, feel free to reopen it or open a different one.

[gusbemacbe]

I was playing with actions block. It appears that fake dotfiles and actions, and dynamic actions do not give effect. Here is my private dotfiles' dotdrop configuration file:

actions:
  always_action: 'date > ~/.dotdrop.log'
config:
  backup: true
  banner: false
  create: true
  dotpath: dotfiles
  keepdot: true
  link_dotfile_default: nolink
  link_on_import: nolink
  longkey: false
variables:
  city: "Lucca, Tuscany, Italy"
dotfiles:
  fake:
    src:
    dst:
    actions:
    - always_action
  d_test-03-ow:
    src: .test-03
    dst: ~/.test-03
  d_test-04:
    src: .test-04
    dst: ~/.test-04
  d_test-05:
    src: .test-05
    dst: ~/.test-05
  f_cities:
    src: .cities
    dst: ~/.cities
profiles:
  general:
    dotfiles:
    - fake
    - d_test-03-ow
    - d_test-04
    - d_test-05
    - f_cities

I did not find the log file in my home, or in the tmp folder nor tmp folder's temporary dotdrop subfolder.

[gusbemacbe]

I tested using the branch user-key-on-import. No effect.

I tested using the actions tests you suggested from the reference regarding the #391.

No effect. The following commands:

dotdrop install -tdaf -c "dotfiles-private/config_user.yml" -p "general"
cd "dotfiles-private" && dotdrop install -tdaf -c "config_user.yml" -p "general"
dotdrop install -tdaf -c "dotfiles-public/config_user.yml" -p "tests"
cd "dotfiles-public" && dotdrop install -tdaf -c "config_user.yml" -p "tests"

[gusbemacbe]

I also tested with another reference and no effect.

[gusbemacbe]

@deadc0de6, finally, I could replicate this problem. These actions are possible only if the directory is not temporary. They are not supported with the option -t/--temp. All the features or options for the installation need to be supported with -t/--temp.

[gusbemacbe]

While you do not solve this issue yet, I have to install without -t. Since I do not want to mess, dirt or pollute my home folder for tests, I created a permanent temporary directory on the tmp folder, and replaced ~ with this folder on all the destinations.

I think you also need to improve the import_config variable for the template variables (https://dotdrop.readthedocs.io/en/latest/template/template-variables/). I created a file .secrets in the private dotfiles folder. I wrote this code in the private dotfiles folder's dotdrop configuration file.

actions:
  presource: source ".secrets"
  postsource: echo "$GIT_USER" > /tmp/dotdrop-xxx/.gituser

I ran the command from the public dotfiles, and it did not find the file because it was in the private dotfiles, not in the public dotfiles.

I had to change the destinations to:

actions:
  presource: source "../dotfiles-private/.secrets"

[deadc0de6]

Thanks for reporting this. Since it was different from your initial issue and I closed it, it might be have been easier to handle this in a new issue.

Indeed, actions are not executed when using -t --temp as mentioned in the doc here:

-t/--temp: Install the dotfile(s) to a temporary directory for review (helping to debug templating issues, for example). Note that actions are not executed in this mode.

Because -t --temp is used to test the installation of dotfiels without polluting one user's home directory, the actions are not executed. I'm not planning on enabling actions with -t --temp as it would defeat the purpose.

What you could do is create a different user with a clean home and test it like that.

Or even define a home variable that you could switch to your real home or to a temporary directory, see below (untested)

actions:
  always_action: 'date > {{@@ myhome @@}}/.dotdrop.log'
config:
  backup: true
  banner: false
  create: true
  dotpath: dotfiles
  keepdot: true
  link_dotfile_default: nolink
  link_on_import: nolink
  longkey: false
variables:
  city: "Lucca, Tuscany, Italy"
  myhome: "/tmp/tmphome"
dotfiles:
  fake:
    src:
    dst:
    actions:
    - always_action
  d_test-03-ow:
    src: .test-03
    dst: "{{@@ myhome @@}}/.test-03"
  d_test-04:
    src: .test-04
    dst: "{{@@ myhome @@}}/.test-04"
  d_test-05:
    src: .test-05
    dst: "{{@@ myhome @@}}/.test-05"
  f_cities:
    src: .cities
    dst: "{{@@ myhome @@}}/.cities"
profiles:
  general:
    dotfiles:
    - fake
    - d_test-03-ow
    - d_test-04
    - d_test-05
    - f_cities

[gusbemacbe]

Indeed, actions are not executed when using -t --temp as mentioned in the doc here:

-t/--temp: Install the dotfile(s) to a temporary directory for review (helping to debug templating issues, for example). Note that actions are not executed in this mode.

Because -t --temp is used to test the installation of dotfiels without polluting one user's home directory, the actions are not executed. I'm not planning on enabling actions with -t --temp as it would defeat the purpose.

Please forgive me for my autism and ADHD, @deadc0de6!

And about import_config variable for the template variables?

[deadc0de6]

Please forgive me for my autism and ADHD, @deadc0de6!

I'm sorry, what is that? I didn't mean to insult you in my answer and if I did, it wasn't on purpose and I apologize.

Can you elaborate on what is the issue with import_config?

[gusbemacbe]

I'm sorry, what is that? I didn't mean to insult you in my answer and if I did, it wasn't on purpose and I apologize.

I know you do not insult. It was my fault because I read overly or misread or oversaw the text and did not pay attention to the info due to my ADHD and autism.

Can you elaborate on what is the issue with import_config?

1. Create a .secrets file right in the dotfiles-private (not on its folder's dotfiles folder) containing the simple text:

   export GIT_USER="gusbemacbe"

2. Add the code on dotfiles-private folder's dotdrop configuration file:

   actions:
     presource: source ".secrets"
     postsource: echo "$GIT_USER" > /tmp/dotdrop-xxx/.gituser

3. Return to the dotfiles-public folder and run the simple command dotdrop install -c "config_user.yml" -p "tests".

4. You run the command and will receive the error .secrets not found because it was in the dotfiles-private folder and not in the dotfiles-public folder. Did you understand it?

If I change from presource: source ".secrets" to presource: source "../dotfiles-private/.secrets" on doftiles-private folder's dotdrop configuration file and if I run that same command from the dotfiles-public folder, it will work because it finds the file because of the ../dotfiles-privates/ path.

[deadc0de6]

Ok, I see. The action source ".secrets" will be executed in the context of the main config and that's the reason it cannot find the file. Can you try with something like the following:

actions:
  presource: source "{{@@ _dotdrop_cfgpath @@}}/.secrets"