Repository: iterative/dvc

Issue:
version: improve link type detection fall back
**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)"




Discussion:
@shcheklein , I couldn't reproduce the issue with the following script: 

```bash
mkdir /tmp/example
cd /tmp/example
python3.7 -m venv .venv
source .venv/bin/activate
pip install dvc
dvc version
```

@ptrcklv , could you provide a reproduction script?
@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.

@shcheklein , @ptrcklv can we close this issue then? :slightly_smiling_face: 
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.  
:eyes: what about using Zsh @shcheklein , @ptrcklv? you can do cool things like the following:


[![asciicast](https://asciinema.org/a/UpDazXtHsyDl9FqNCT1HOre0Z.svg)](https://asciinema.org/a/UpDazXtHsyDl9FqNCT1HOre0Z)

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_)
@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.)
@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`?
@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
> 
> > 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. 
> 
> "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?
> It can be the second example for the Troubleshooting

p.s. Ivan is talking about iterative/dvc.org/pull/875 FYI
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.
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`
@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`.
```
By the way, @jorgeorpinel , @shcheklein , is `cache.shared group` documented? Couldn't find it when searching for `cache.shared` on the docs.
@mroutis no, unfortunately not - https://github.com/iterative/dvc.org/issues/497
@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`.
Okay, I think it comes down to this difference:

```bash
$ 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 

```bash
$ 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)
```

@shcheklein , and couldn't someone migrate the cache to a _shared_ one afterwards?
@mroutis probably they could. It was just best guess about the comment we have.
@shcheklein, I see :slightly_smiling_face: 

I would rethink having the warning in the first place, as I stated earlier.
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 
@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
```

2. 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.



Resolving patch:
diff --git a/dvc/command/version.py b/dvc/command/version.py
--- a/dvc/command/version.py
+++ b/dvc/command/version.py
@@ -10,7 +10,7 @@
 from dvc.exceptions import DvcException, NotDvcRepoError
 from dvc.scm.base import SCMError
 from dvc.system import System
-from dvc.utils import relpath
+from dvc.utils import error_link
 from dvc.utils.pkg import PKG
 from dvc.version import __version__
 
@@ -59,13 +59,7 @@ def run(self):
                     fs_type = self.get_fs_type(repo.cache.local.cache_dir)
                     info.append(f"Cache directory: {fs_type}")
             else:
-                logger.warning(
-                    "Unable to detect supported link types, as cache "
-                    "directory '{}' 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.".format(relpath(repo.cache.local.cache_dir))
-                )
+                info.append("Cache types: " + error_link("no-dvc-cache"))
 
         except NotDvcRepoError:
             root_directory = os.getcwd()


Test patch: