Dvc: RFC: introduce `dvc version` command

[ei-grad]

I propose to introduce the dvc version command, which would output the system/environment information together with the dvc version itself.

Example output:

$ dvc version
DVC version: 0.32.1
Python version: 3.7.2 (default, Jan 10 2019, 23:51:51)
[GCC 8.2.1 20181127]
VIRTUAL_ENV: /home/ei-grad/.virtualenvs/dvc
Platform: Linux 5.0.2-arch1-1-ARCH
LSB Release: lsb-release command not found
Cache: hardlink (symlink:yes reflink:no fs:ext4)

The current template of the bug issues on Github asks the user to add platform and installation method description. I think it would be nice to have the dvc's own method to capture the important information from the environment.

What other information should we include here?

Some things to refine:

• [ ] The "cache" part needs clarification.
• [ ] How it would coexist dvc --version? What are the best practices faced in other software?
• [ ] Do we have something special related to PyInstaller builds to collect?
• [ ] Are there any libraries which versions should be also included in such output? Should it include e.g. GitPython version?

[dmpetrov]

Great idea. I especially like Cache: hardlink (symlink:yes reflink:no fs:ext4). I'd only remove symlink part - can we work on a system when symlink are not supported?

It would be great to have method of installation. Basically, we need everything that we ask in bug reports.

Btw.. is Python information useful? Also, which of DVC packages include Python (except Windows)?

Do we need VIRTUAL_ENV: /home/ei-grad/.virtualenvs/dvc? It contains a path which you probably don't want to share in a bug report.

[shcheklein]

Love the idea to print more information (especially, caching type).

Few questions/options to consider:

1. Why do we need a separate command for that, it's not clear. Why is --version alone not enough.
2. Would it be better to dump more information only when we run dvc --version in the verbose mode? And keep it clean and simple by default.
3. I think we still could support something like dvc cache type that by default prints actual DVC cache type being used.

[ghost]

Why do we need a separate command for that, it's not clear. Why is --version alone not enough.

@shcheklein, usually a command is more detailed, also flags/options are used when the first argument isn't expected to be a sub-command, for example:

❯ docker version
Client:
 Version:           18.09.3-ce
 API version:       1.39
 Go version:        go1.12
 Git commit:        774a1f4eee
 Built:             Thu Feb 28 20:38:40 2019
 OS/Arch:           linux/amd64
 Experimental:      false

❯ docker --version
Docker version 18.09.3-ce, build 774a1f4eee

Would it be better to dump more information only when we run dvc --version in the verbose mode? And keep it clean and simple by default.

Do you mean like dvc --verbose --version ?

Do we need VIRTUAL_ENV: /home/ei-grad/.virtualenvs/dvc? It contains a path which you probably don't want to share in a bug report.

Indeed, @dmpetrov , people usually mask their paths, maybe we can have something like virtual environment: [cygwin, conda, venv, pipenv, none].

---

I love the idea in general, @ei-grad :fire: ! I would add:

• remotes: [s3, local, ssh, azure, gcs, none]
• scm: [git, none]

(Usually, a lot of the questions are "remote" related, so it is cool to have at least what remote they have configured)

Maybe we can have a dvc info command, reassembling the docker info one:

Containers: 14
 Running: 3
 Paused: 1
 Stopped: 10
Images: 52
Server Version: 1.10.3
Storage Driver: devicemapper
 Pool Name: docker-202:2-25583803-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 1.68 GB
 Data Space Total: 107.4 GB
 Data Space Available: 7.548 GB
 Metadata Space Used: 2.322 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.145 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.107-RHEL7 (2015-12-01)
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: null host bridge
Kernel Version: 3.10.0-327.el7.x86_64
Operating System: Red Hat Enterprise Linux Server 7.2 (Maipo)
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 991.7 MiB
Name: ip-172-30-0-91.ec2.internal
ID: I54V:OLXT:HVMM:TPKO:JPHQ:CQCD:JNLC:O3BZ:4ZVJ:43XJ:PFHZ:6N2S
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Username: gordontheturtle
Registry: https://index.docker.io/v1/
Insecure registries:
 myinsecurehost:5000
 127.0.0.0/8

[shcheklein]

@mroutis looks good!

[ghost]

Related: https://github.com/mahmoud/boltons/blob/master/boltons/ecoutils.py

    $ python -m boltons.ecoutils
    {
      "_eco_version": "1.0.0",
      "cpu_count": 4,
      "cwd": "/home/mahmoud/projects/boltons",
      "fs_encoding": "UTF-8",
      "guid": "6b139e7bbf5ad4ed8d4063bf6235b4d2",
      "hostfqdn": "mahmoud-host",
      "hostname": "mahmoud-host",
      "linux_dist_name": "Ubuntu",
      "linux_dist_version": "14.04",
      "python": {
        "argv": "boltons/ecoutils.py",
        "bin": "/usr/bin/python",
        "build_date": "Jun 22 2015 17:58:13",
        "compiler": "GCC 4.8.2",
        "features": {
          "64bit": true,
          "expat": "expat_2.1.0",
          "ipv6": true,
          "openssl": "OpenSSL 1.0.1f 6 Jan 2014",
          "readline": true,
          "sqlite": "3.8.2",
          "threading": true,
          "tkinter": "8.6",
          "unicode_wide": true,
          "zlib": "1.2.8"
        },
        "version": "2.7.6 (default, Jun 22 2015, 17:58:13) [GCC 4.8.2]",
        "version_info": [
          2,
          7,
          6,
          "final",
          0
        ]
      },
      "time_utc": "2016-05-24 07:59:40.473140",
      "time_utc_offset": -8.0,
      "ulimit_hard": 4096,
      "ulimit_soft": 1024,
      "umask": "002",
      "uname": {
        "machine": "x86_64",
        "node": "mahmoud-host",
        "processor": "x86_64",
        "release": "3.13.0-85-generic",
        "system": "Linux",
        "version": "#129-Ubuntu SMP Thu Mar 17 20:50:15 UTC 2016"
      },
      "username": "mahmoud"
    }

It might be more than what we need, but it is a good starting point (and it relies only on the standard library)

[algomaster99]

I am currently working on this issue. Will submit a PR after I figure it out :smile:.

[efiop]

Fixed by #1963

[efiop]

Leaving open for the last part: listing if dvc is installed from binary or not.

[algomaster99]

@efiop where is the binary code released? Are we talking about the .exe file?

[efiop]

@algomaster99 We have a helper to determine whether or not dvc is installed from binary or not. Simply use is_binary something like:

from dvc.utils import is_binary

info += "Binary: {}".format(is_binary())

[algomaster99]

@efiop but where can we find the binary release? There are only .deb, .exe, .rpm and .pkg in the releases.

[efiop]

@algomaster99 Yes, all of those contain binaries built by pyinstaller. Non-binary releases are the ones on homebrew formulas and pypi.

[shcheklein]

we need to update docs