bpo-31904: Fix site and sysconfig modules for VxWorks RTOS

[pxinwr]

VxWorks RTOS has no home directory for users. Sure it can't recognize the "~" directory. sys.prefix is always set as "/usr" on VxWorks. So for site and sysconfig module, we just simply set the user base as sys.prefix for users. And user site packages path will be sys.prefix/lib/pythonX.Y/site-packages

https://bugs.python.org/issue31904

[vstinner]

Would you mind to test the expected user_base value? Something like:

self.assertEqual(user_base, sys.prefix) 

[pxinwr]

Added.

[vstinner]

I suggest:

Suggested change

	Fix site and sysconfig modules for VxWorks RTOS
	Fix site and sysconfig modules for VxWorks RTOS which has no home directories.

[pxinwr]

modified as suggested.

[vstinner]

What does os.path.expanduser('~') return on VxWorks?

Instead of changing sysconfig and site, maybe posixpath.expanduser() could get a special case to return sys.prefix?

[vstinner]

Would you mind to move it after "if env_base.." and before "def joinuser..." to clarify that the joinuser() function makes no sense on VxWorks?

Same remark for site.py which has copy of this function.

[pxinwr]

Cool. Performance is also better with your idea. Modified.

[vstinner]

Would mind to try to write the different cases as a bullet point for readability?

Default value: * :file:`~/.local/lib/python{X.Y}/site-packages` on UNIX and non-framework macOS builds. * :file:`~/Library/Python/{X.Y}/lib/python/site-packages` on macOS framework builds. * :file:`{%APPDATA%}\\Python\\Python{XY}\\site-packages` on Windows. * :file:`{sys.prefix}/lib/python{X.Y}/site-packages` on VxWorks. This directory is a site directory, (...) 

Same request for USER_BASE below.

Note: if you update the doc, please replace "Mac OS X" with "macOS" (as I did).

[pxinwr]

Done.

[pxinwr]

What does os.path.expanduser('~') return on VxWorks?

It depends on whether user management feature is enabled or not on VxWorks. By default this feature is disabled. And expanduser() will encounter KeyError then returning the unchanged path. If user management feature is enabled, the pw_dir attribute will be None so that expanduser() will raise exception. So I created PR 23530 to fix this.

Instead of changing sysconfig and site, maybe posixpath.expanduser() could get a special case to return sys.prefix?

Looks sys.prefix is for system-wide settings whereas the return value of posixpath.expanduser() is used for user specific settings. If we return sys.prefix from posixpath.expanduser(), any chance things get mixed up to mess? Now I get stuck on which one, None or sys.prefix should be returned for user base and user site. What is your idea? If determined to None, ENABLE_USER_SITE should also be set to False. Since sys.prefix has been added to sys.path, so setting user base to None has no impact on sys.path.

[vstinner]

LGTM, this change looks reasonable.

The relationship between ENABLE_USER_SITE=False and (USER_SITE=None, USER_BASE=None) may be enhanced to make the code even more generic, but I don't see how it should be done. I'm fine with the current code. Also, sysconfig._getuserbase() doesn't have ENABLE_USER_SITE, so it's ok to use None as a marker "there is no user directory".

[vstinner]

posixpath.expanduser() has been modified on VxWorks by PR #23530 (commit 75dabfe): return the path unmodified if pwd.getpwuid().pw_dir is None. This change doesn't help site/sysconfig, so this PR remains useful/relevant.

[vstinner]

The second version of the PR is way better, thanks for the update.

[pxinwr]

@vstinner Thanks for your effort.