Should `doctor` also print relevant env vars "debugging"?

[jasonkarns]

The rbenv-doctor utility is fantastic for debugging rbenv installations. Similarly related to what the doctor utility scans for, is inspecting the status of env vars that are relevant to rbenv, ruby, and rubygems. The rbenv-env plugin exists for that purpose at the moment.

I'm curious around a few thoughts that interrelate to one another.

Firstly, does it make sense for rbenv-doctor to be distributable as an rbenv plugin, such that rbenv doctor is an available subcommand? Strictly speaking, one could already install this as a plugin. But doing so in its present form would also add rbenv installer as a subcommand, which is much less useful.

Secondly, would it make sense for doctor to gain env-var introspection capability? Either as a separate subcommand, or as a part of doctor's own output? Perhaps by merging with rbenv-env plugin or combining effort?

(These thoughts interrelate because for env-var introspection to be effective, I think it would really need to be run as a proper plugin so that it's seeing the environment the way rbenv-managed ruby commands do.)

[mislav]

Firstly, does it make sense for rbenv-doctor to be distributable as an rbenv plugin, such that rbenv doctor is an available subcommand?

I don't think so, since the purpose of the doctor command is to point out potential errors in rbenv setup, and if rbenv setup is currently broken, rbenv subcommands and plugins might not work.

Secondly, would it make sense for doctor to gain env-var introspection capability? Either as a separate subcommand, or as a part of doctor's own output?

I can totally imagine that it would be useful that rbenv-doctor, by default, prints relevant environment variables! It could do that on its own to avoid installing yet another plugin.

[jasonkarns]

Hrm. I'm unsure where I want to proceed from here. 😄

If we assume that rbenv-doctor gains the ability to print relevant env vars, I would find rbenv-doctor to then be a superset of the rbenv-env plugin. I personally already have rbenv-doctor installed as a plugin and it works well similar to brew doctor for assessing the relative "health" or state of the whole rbenv suite. (The only downside is that this adds rbenv-installer to subcommands and shell completion.)

I certainly agree that rbenv-doctor should not only be installed as a plugin. (for the debugging reasons you listed above) But it does work well as an introspection plugin as-is. However, if there is no desire to support rbenv-doctor as a plugin, then it could never serve as a replacement to rbenv-env (even if it gained env var inspection capability).