Easier to Post Version Numbers on Github Issues

[koaning]

Description of Problem:

When I write a bug request, I gotta do a whole lot of accounting.

We need this, but this is effort from the user. And techies, they don't like to do manual labor.

Overview of the Solution:

I propose that we add a verbose flag to the version command that will output information that a user can just copy.

> rasa --version --verbose
**Enrivonment Info**
Darwin 19.3.0 - posix
Python 3.6.8
Rasa 1.9.6
Rasa-SDK 1.9.0

This information saves the user time and may make it easier for folks to give good issues. We should be able to get all the rasa packages that are installed with versions as well as the operating system in one go. Heck, we might even be able to generate a nice table format :)

Definition of Done:

[koaning]

I wouldn't mind picking this up but I would like to get a green light before attempting this.

[eibhleag]

This feels like a @RasaHQ/production-engineers issue so best to double check with them 🙂

[wochinge]

I think it's a cool idea and you can of course do it 👍 Let's just get on more opinion on it 🙂 @erohmensing What do you think?

[erohmensing]

Yeah seems like a great idea to me! So long as it's making sure to check for things in the right environments and such :)

[koaning]

I need some feedback on design.

Question One: How to Call it

There's multiple places in the cli where I can add this behavior and I'm not sure where we'd prefer it.

Behavior One

We could add a --verbose flag.

> rasa --version --verbose

This means that I have to add a flag to the global rasa command that is only valid when --version is set. Setting --verbose usually has an effect on the logger, which isn't the case here so this feels like an anti-pattern.

Behavior Two

We could also just add this to the original command rasa --version.

> rasa --version
Python Environment:
3.6.8 (v3.6.8:3c6b436a57, Dec 24 2018, 02:04:31) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)]
Rasa Version: 1.9.7
Rasa SDK Version: 1.9.0
Rasa X Version: 0.27.7

This might not be what the user expects when we call --version.

Behavior Three

We could also put all of this in another command.

> rasa info
Python Environment:
3.6.8 (v3.6.8:3c6b436a57, Dec 24 2018, 02:04:31) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)]
Rasa Version: 1.9.7
Rasa SDK Version: 1.9.0
Rasa X Version: 0.27.7

The idea here is that by having a dedicated command for info we can also report what is and what isn't installed. This opens the door to things like;

> rasa info --extra
Python Environment:
3.6.8 (v3.6.8:3c6b436a57, Dec 24 2018, 02:04:31) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)]

Rasa Version: 1.9.7
Rasa SDK Version: 1.9.0
Rasa X Version: 0.27.7
Sanic Version: 19.12.2
Tensorflow Version: 2.1.0
SpaCy Version: 2.2.4

This can also show versions of packages that commonly cause problems. We could also add fancy features like output formats (markdown/tables).

Note that I am not 100% set on the info command (I've merely copied what spaCy does). We could instead call it debug-info or something like that.

Question Two: Expected Behavior

Suppose that Rasa X is not installed. Which of these two outputs do we prefer?

Python Environment:
3.6.8 (v3.6.8:3c6b436a57, Dec 24 2018, 02:04:31) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)]
Rasa Version: 1.9.7
Rasa SDK Version: 1.9.0

or

Python Environment:
3.6.8 (v3.6.8:3c6b436a57, Dec 24 2018, 02:04:31) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)]
Rasa Version: 1.9.7
Rasa SDK Version: 1.9.0
Rasa X is not Installed. 

I think for debug purposes we prefer to be explicit so that means the latter is preferable, @erohmensing @wochinge you agree?

[koaning]

Question Three

After checking what spaCy does;

python -m spacy info

============================== Info about spaCy ==============================

spaCy version    2.2.4                         
Location         /Users/vincent/Development/rasa/venv/lib/python3.6/site-packages/spacy
Platform         Darwin-19.3.0-x86_64-i386-64bit
Python version   3.6.8

Do we also want to log the directory of the virtualenv? Are there any other things that we might want to automatically add here?

[erohmensing]

1. I don't think adding a global flag to rasa only used here sounds like the right approach. Perhaps we could use --debug for this purpose instead? As it's a pattern we use a lot in the CLI to give more output, and we're implementing this for better debugging, after all. But maybe you would disagree with that bc of Setting --verbose usually has an effect on the logger, which isn't the case here so this feels like an anti-pattern.

Otherwise i'd probably go with the second option, but order them by relevance to rasa/specificity, i.e. rasa, rasa sdk, rasa x, python version, OS.

The idea here is that by having a dedicated command for info we can also report what is and what isn't installed.

I don't think this is necessary -- it's not super common that we need to ask for these versions, and you end up having to decide what goes in. If we need more info we can always ask them to pip list | grep <whatever>.

2. Mm, I'm not sure, because it could only find the local rasa-x package (which is how we don't prefer it installed) so i think seeing that "it's not installed" all the time might be confusing? In any case, I think it makes sense to refer to thinks by their pip package names to be clearer about that.

3. I think virtualenv info could probably be helpful to make sure that people are in the environment that they think they're in 🤔