Dvc: version: improve link type detection fall back

[shcheklein]

To reproduce:

dvc version outside of any DVC repo.

Output:

WARNING: Unable to detect supported link types, as cache directory '.dvc/cache' doesn't exist. It is usually auto-created by commands such as `dvc add/fetch/pull/run/import`, but you could create it manually to enable this check.

It should instead generate a regular output and either omit the link type completely or print some special value "link: (run inside repo)"

[ghost]

@shcheklein , I couldn't reproduce the issue with the following script:

mkdir /tmp/example
cd /tmp/example
python3.7 -m venv .venv
source .venv/bin/activate
pip install dvc
dvc version

[ghost]

@ptrcklv , could you provide a reproduction script?

[shcheklein]

@mroutis me neither! And from the code perspective I don't see a bug. It might be I had a .dvc somewhere in the ~ (you know it happens from time to time when you do dvc init at the very top) - this is the only explanation that comes to my mind.

[ghost]

@shcheklein , @ptrcklv can we close this issue then? :slightly_smiling_face:

[ptrcklv]

True, does not occur in arbitrary test dir. I could reproduce the error when I ran dvc version in my local dvc repo, i.e. in a code directory. Actually it is not a dvc repo but there is a .dvc folder, which fooled me, too.

[ghost]

:eyes: what about using Zsh @shcheklein , @ptrcklv? you can do cool things like the following:

any suggestions on how to leverage this? I didn't want to add dvc --version because it can take quite some time to compute (_no bueno_)

[ghost]

@shcheklein , @ptrcklv can you go to the referenced PR on spaceship-prompt and add your comments? (e.g. _"this is not needed, please, close it immediately"_, _"neat, but won't use"_, etc.)

[shcheklein]

@ptrcklv

Actually it is not a dvc repo but there is a .dvc folder, which fooled me, too.

Is that .dvc directory a leftover from some experiments or is a coincidence and you had it even before .dvc?

[shcheklein]

@mroutis I think to the most part it's an UI ticket, we should just update the message to be more explicit:

"Unable to detect supported link types. You run this command inside DVC repo (.dvc exists) but it looks it has been just initialized as cache directory ("show here actual path to the cache dir from config") does not exist yet. It is usually auto-created by commands such as dvc add/fetch/pull/run/import, but you could create it manually to enable this check. "

It can be the second example for the Troubleshooting cc @jorgeorpinel and we can simplify a message and put a link to the command reference ... I even think if we need to introduce a short-cut similar to man.dvc.org - like error.dvc.org\<code> that redirects to the Troubleshooting section with a specific error.

[ptrcklv]

@ptrcklv

Actually it is not a dvc repo but there is a .dvc folder, which fooled me, too.

Is that .dvc directory a leftover from some experiments or is a coincidence and you had it even before .dvc?

No it's the .dvc which is on the dvc master branch. I did your reproduction steps from the very first comment in this issue in my local dvc repo folder (coincidently had been there already). I was not aware of that .dvc folder there, so I got fooled since I thought i was not in a DVC repo. In a clean test folder I could also not reproduce the issue.

[ptrcklv]

"Unable to detect supported link types. You run this command inside DVC repo (.dvc exists) but it looks it has been just initialized as cache directory ("show here actual path to the cache dir from config") does not exist yet. It is usually auto-created by commands such as dvc add/fetch/pull/run/import, but you could create it manually to enable this check. "

@shcheklein: Since you recommend to the user to create the cache dir manually, could dvc version command not simply create the empty cache dir when called within a dvc repo and so the error message could be avoided completely?

[jorgeorpinel]

It can be the second example for the Troubleshooting

p.s. Ivan is talking about iterative/dvc.org/pull/875 FYI

[jorgeorpinel]

Hi! To reproduce this just create an empty DVC project first, then run dvc version inside. See https://github.com/iterative/dvc/issues/3122#issue-548659601 for full script.

[ghost]

do we need this warning at all? :thinking: The user might not care about the link type when running dvc version. As far as I remember, the _link type_ got included to give us more context when a user is reporting an issue.

@ptrcklv , I'm with you on this one, I'd prefer dvc version to create the .dvc/cache

[shcheklein]

@mroutis please, consider also this comment from the version.py:

            # cache_dir might not exist yet (e.g. after `dvc init`), and we
            # can't auto-create it, as it might cause issues if the user
            # later decides to enable shared cache mode with
            # `dvc config cache.shared group`.

[ghost]

By the way, @jorgeorpinel , @shcheklein , is cache.shared group documented? Couldn't find it when searching for cache.shared on the docs.

[shcheklein]

@mroutis no, unfortunately not - https://github.com/iterative/dvc.org/issues/497

[ghost]

@shcheklein , not sure how it will affect cache.shared.

Just to be clear, using dvc version outside a DVC repository should not create .dvc/cache.

[shcheklein]

Okay, I think it comes down to this difference:

$ dvc init
$ dvc version
$ ls -lh .dvc
(`.dvc/cache` exists with some default permissions, user and group)
$ dvc config cache.shared smt 
$ ls -lh .dvc
(`.dvc/cache` still has defaults)

vs

$ dvc init
$ dvc version
$ ls -lh .dvc
(does not exist)
$ dvc config cache.shared smt 
...
...
$ dvc pull (or something else)
$ ls -lh .dvc
(`.dvc/cache` has proper permissions)

[ghost]

@shcheklein , and couldn't someone migrate the cache to a _shared_ one afterwards?

[shcheklein]

@mroutis probably they could. It was just best guess about the comment we have.

[ghost]

@shcheklein, I see :slightly_smiling_face:

I would rethink having the warning in the first place, as I stated earlier.

[IvanRubanov]

Hello guys. I came across this issue as it is labeled as a "good first issue". Do I understand correctly that the conclusion is just to remove this warning or I misunderstood something? @shcheklein @mroutis

[shcheklein]

@IvanRubanov I guess there are two options:

1. Instead of that warning show an entry in the dvc version output:

DVC version: 1.6.0+adce62
---------------------------------
Platform: Python 3.8.5 on macOS-10.15.6-x86_64-i386-64bit
Cache types: https://error.dvc.org/unable-to-detect-cache-type
Supports: All remotes

1. Create some temp dir on the same path as would dvc push\pull create cache. By default it's created as .dvc/cache. And use it to detect the supported cache types.

I prefer the second one, unless there are some issue that I'm missing about it.