[bug] v1.11.0 is missing 'distro' in requirements file

[mdentremont]

ModuleNotFoundError: No module named 'distro'

[deadc0de6]

@mdentremont thanks for submitting this bug however could you provide how you installed dotdrop

After checking it seems distro is in

• pypi: https://pypi.org/pypi/dotdrop/1.11.0/json (so also probably in brew and snap)
• is in the requirements.txt file
• is in aur package

Also having information on your setup (OS, distro, etc) could help, thanks

[mdentremont]

Interesting, I do see it in the requirements.txt file.

I'm installing it via pip3 install -r dotdrop/requirements.txt --user, and my versions/env details:

╭─[19:52:49] ~  <mdentremont>
╰─➤  pip3 --version                                                                                                                                                                    
pip 22.0.4 from /home/spin/.pyenv/versions/3.10.4/lib/python3.10/site-packages/pip (python 3.10)
╭─[19:52:55] ~  <mdentremont>
╰─➤  python3 --version                                                                                                                                                                 
Python 3.10.4
╭─[19:53:07] ~  <mdentremont>
╰─➤  uname -a                                                                                                                                                                          
Linux spin 5.10.68+ #1 SMP Fri Dec 3 10:04:10 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

My workaround was to do pip3 install -r dotdrop/requirements.txt distro --user instead - but that shouldn't improve things.. Maybe my environment is getting confused by the python_version > '3.5'

[deadc0de6]

I was able to reproduce.

The way to fix this is indeed to reinstall the requirements defined in requirements.txt (for example withpip3 install -r dotdrop/requirements.txt --user).

This happens if you use dotdrop as a submodule, which gets updated through the dotdrop.sh but that script does not automatically handle the (re-)installation of dependencies (not knowing what env setup users are using, with or without --user, etc).

Not sure how I should fix that in an elegant way. I prefer not to force any call to pip not knowing how dependencies were initially installed. This wasn't an issue since I don't expect the dependencies to change much but well, it does ;-)

Sorry for the trouble, if you have an idea on how to solve this nicely, let me know.

[deadc0de6]

I have added a note in the submodule installation doc:

If you happened to encounter ModuleNotFoundError error after an update, it means the dependencies have changed and you should re-install dependencies with pip3 install --user -r dotdrop/requirements.txt

[mdentremont]

My situation was actually happening with a fresh install - it checks out the latest version of the submodule, runs the install command I listed above, and for some reason distro isn't installed.

I tried running the pip install multiple times and the only way I could get distro to be pulled down was to use the workaround command above.

[deadc0de6]

Ouch. Ok so you did run the pip3 install --user -r dotdrop/requirements.txt which contained distro but that wasn't installed? Any error warning from pip or anything?

[mdentremont]

Ah, I figured out the issue -- it's that running:

~/dotfiles mdentremont % ./dotdrop.sh install --force --cfg config-linux.yaml

Ends up updating dotdrop:

Submodule path 'dotdrop': checked out 'aa3defd11752247909e03eaf14da197a6eda90f7'

So even though my submodules are all up-to-date and requirements installed, dotdrop goes ahead and updates itself on start.

[mdentremont]

It seems to modify the checked out submodule version even when I just run ./dotdrop.sh --help:

~/dotfiles mdentremont % ./dotdrop.sh --help
Submodule path 'dotdrop': checked out 'ebd31e41aa469b3b7e79174d8d9891cee147b674'
Submodule path 'dotdrop': checked out 'aa3defd11752247909e03eaf14da197a6eda90f7'

[mdentremont]

I think I have it, I was running dotdrop.sh (old version) instead of dotdrop/dotdrop.sh

[mdentremont]

Whoops, it seems that's how I'm supposed to do it 😛 - bootstrap.sh creates that file

[mdentremont]

So it seems that running ./dotdrop.sh triggers the auto-upgrade, but ./dotdrop/dotdrop.sh does not:

╭─[12:48:41] ~/dotfiles  <mdentremont>
╰─➤  ./dotdrop.sh
Submodule path 'dotdrop': checked out 'ebd31e41aa469b3b7e79174d8d9891cee147b674'
Submodule path 'dotdrop': checked out 'aa3defd11752247909e03eaf14da197a6eda90f7'
Usage:
  dotdrop install   [-VbtfndDaW] [-c <path>] [-p <profile>]
                                 [-w <nb>] [<key>...]
  dotdrop import    [-Vbdfm]     [-c <path>] [-p <profile>] [-i <pattern>...]
                                 [--transr=<key>] [--transw=<key>]
                                 [-l <link>] [-s <path>] <path>...
  dotdrop compare   [-LVbz]      [-c <path>] [-p <profile>]
                                 [-w <nb>] [-C <file>...] [-i <pattern>...]
  dotdrop update    [-VbfdkPz]   [-c <path>] [-p <profile>]
                                 [-w <nb>] [-i <pattern>...] [<path>...]
  dotdrop remove    [-Vbfdk]     [-c <path>] [-p <profile>] [<path>...]
  dotdrop files     [-VbTG]      [-c <path>] [-p <profile>]
  dotdrop detail    [-Vb]        [-c <path>] [-p <profile>] [<key>...]
  dotdrop profiles  [-VbG]       [-c <path>]
  dotdrop --help
  dotdrop --version
╭─[12:48:46] ~/dotfiles  <mdentremont>
╰─➤  dotdrop/dotdrop.sh                                                                                                    1 ↵
Usage:
  dotdrop install   [-VbtfndDaW] [-c <path>] [-p <profile>]
                                 [-w <nb>] [<key>...]
  dotdrop import    [-Vbdfm]     [-c <path>] [-p <profile>] [-i <pattern>...]
                                 [--transr=<key>] [--transw=<key>]
                                 [-l <link>] [-s <path>] <path>...
  dotdrop compare   [-LVbz]      [-c <path>] [-p <profile>]
                                 [-w <nb>] [-C <file>...] [-i <pattern>...]
  dotdrop update    [-VbfdkPz]   [-c <path>] [-p <profile>]
                                 [-w <nb>] [-i <pattern>...] [<path>...]
  dotdrop remove    [-Vbfdk]     [-c <path>] [-p <profile>] [<path>...]
  dotdrop files     [-VbTG]      [-c <path>] [-p <profile>]
  dotdrop detail    [-Vb]        [-c <path>] [-p <profile>] [<key>...]
  dotdrop profiles  [-VbG]       [-c <path>]
  dotdrop --help
  dotdrop --version

[mdentremont]

But that makes sense -- in both cases the:

  git submodule update --init --recursive
  git submodule update --remote dotdrop

gets triggered, but when that happens inside of the submodule folder nothing happens.

[mdentremont]

So for me, the workaround for my init script can be to also do git submodule update --remote dotdrop before installing my requirements

[deadc0de6]

Dotdrop when used as a submodule does update itself (to the latest commit of the master branch, not to the latest version/tag) unless the environment variable DOTDROP_AUTOUPDATE is set to no. It's all documented here.

You can have a look here and here on how to upgrade/downgrade dotdrop when using it as a submodule.

The dotdrop.sh will update submodules but since it pivots itself to the directory where it is located, calling dotdrop/dotdrop.sh won't update anything since the sub-directory dotdrop/ does no have any submodules.

dotdrop.sh is a simple bash script so you can also modify it to your needs. The bootstrap.sh script does copy it on installation so it won't be overwritten by dotdrop updates.