bin/activate should update the manpath (not just the path)

[ghost]

Currently, before activating a virtualenv, my system has the following $PATH and manpath:

~/my_venv$ virtualenv --version
15.1.0
~/my_venv$ echo $PATH
/usr/local/bin:/usr/bin:/bin
~/my_venv$ manpath
/usr/local/man:/usr/local/share/man:/usr/share/man

After activating the virtualenv, the $PATH is updated (which is a good thing - this is the whole point of virtualenv), but the manpath isn't:

(my_venv) ~/my_venv$ echo $PATH
/home/sampablokuper/my_venv/bin:/usr/local/bin:/usr/bin:/bin:
(my_venv) ~/my_venv$ manpath
/usr/local/man:/usr/local/share/man:/usr/share/man

This means that reading the documentation locally for any packages installed into a virtualenv is impossible or impractical. Therefore, bin/activate should update not only the path, but also the manpath.

(The deactivate command should correspondingly reverse the changes to both the path and the manpath.)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Just add a comment if you want to keep it open. Thank you for your contributions.

[ghost]

@stale (or, since you are a bot, your operator): no commit has been filed to fix this issue (or at least, commit has been filed that references this issue), so presumably the issue is still unfixed. Please therefore re-open it. Thanks.

[gaborbernat]

Seems no longer an issue as no one reported it in 3 years.

[jakkdl]

No this is still a thing, although I'm guessing it's a bit too obscure for too many people to perk up about it - but I subscribed to this issue a few months ago as I was frustrated by it myself.

$ man -w # print manpaths
/usr/local/man:/usr/share/man
$ mkdir /tmp/foo; cd /tmp/foo
$ man ipython
man: No entry for ipython in the manual.
$ python -m venv .venv
$ source .venv/bin/activate
$ pip install ipython
$ man ipython
man: No entry for ipython in the manual.
$ man -m .venv/share/man -w ipython # -m appends path to be searched, -w prints the path instead of displaying
man: outdated mandoc.db lacks ipython(1) entry, run makewhatis /tmp/foo/.venv/share/man
/tmp/foo/.venv/share/man/man1/ipython.1

[gaborbernat]

Please fill a PR to address it.

[jakkdl]

Digging into this a bit more, seems like it's only an issue if mandoc is used as the man provider - not if using man-db. man-db uses $PATH to find man-pages:

SEARCH PATH

By default, man-db examines the user's $PATH. For each path_element found there, it adds manpath_element to the search path.

If there is no MANPATH_MAP line in the configuration file for a given path_element, then it adds all of path_element/../man, path_element/man, path_element/../share/man, and path_element/share/man that exist as directories to the search path.

At least on my (arch linux) system, $MANPATH isn't actually defined at all (and that seems to be a common thing), and if we straight up add $VIRTUALENV/share/man to $MANPATH then it seems to override the default manpaths - so you can no longer look up man pages for system commands. (the SE link earlier mentions using manpath -g - but that's only a thing with man-db).

So I think the way to address it would be to define an alias that overrides man, and adds -m $VIRTUAL_ENV. You're still left with an issue of it complaining about outdated/missing mandoc.db, and pip install doesn't automatically run makewhatis (so maybe an alias for pip as well ... unless you use poetry/hatch/whatever), so in the case of a package being available both in the virtualenv and in the system adding the above alias would be a negative.

So given that this depends on man provider, and at least in my case it can be resolved simply by installing man-db instead, and that any mandoc users would have to resolve makewhatis issues with their own custom aliases/functions/mandoc config, I think this should be closed as a won't-fix.

Hopefully the above can be of use for any other people stumbling upon this issue~ :)

[gaborbernat]

Closing as per above.