Python 3.6 on Windows - does a python3 alias get created by installation?

Eryk Sun eryksun at gmail.com
Wed Oct 9 17:07:20 EDT 2019


On 10/9/19, Malcolm Greene <python at bdurham.com> wrote:
>
> @Dan: Yes, symlinks would be a good work around.

Assuming the file system supports symlinks (e.g. NTFS, but not FAT32),
a relative symlink in the directory beside python.exe works fine, e.g.
"python3.exe" -> "python.exe". Putting the symlink in another
directory will not work unless you also symlink "python36.dll",
"python3.dll", and "vcruntime140.dll". The problem is that loader
doesn't resolve the application directory as the final path, so these
DLLs won't be found unless they're all symlinked together.

Symlinks can be created via Python's os.symlink, CMD's mklink, or
PowerShell's new-item with "SymbolicLink" as the ItemType and the
target as its Value. Typically you need SeCreateSymbolicLinkPrivilege,
which can be granted to you or one of your groups (e.g. the
Authenticated Users group). When the privilege is obtained this way,
an administrator doesn't have to elevate to create symlinks.

If the target is in another directory, the better solution in Windows
is a shell link (i.e. a ".lnk" file), aka a "shortcut". Shell links
work via the Windows shell API ShellExecuteExW. Console shells such as
CMD and PowerShell fall back on ShellexecuteExW if CreateProcessW
fails.

The simplest way to create a shell link is via the Windows GUI shell,
Explorer. To inherit the working directory of the parent process,
leave the link's "start in" field empty. Also, add ".LNK" to the
system PATHEXT environment variable to allow finding link files
without having to include the ".lnk" file extension, i.e. to be able
to run "python3.lnk <...>" as just "python3 <...>".



More information about the Python-list mailing list