-
Pierre-Yves David authored
This code is no longer used as the python packaging echo system evolved. This code was introduced in 10da5a1f25dd, with two feature in mind: - Mercurial may be installed into a non-standard location without having to set PYTHONPATH. - Multiple installations can use Mercurial from different locations. As a side effect it also provided performance improvement at a time where the `sys.path` could be greatly inflated from setuptools `.pth` files. And it also protected from incompatible directory within the `$PTYHONPATH` variable. Both of these benefit has faded overtime as `.pth` are less common and `$PYTHONPATH` is less used (as both where creating issue to more than just Mercurial). The initial motivation (easily install Mercurial anywhere), can now be handled by a new generation of tool like pipx or uv, so it is less of a concern. Regardless of all the above, the current code is no longer used. The evolution of python packaging means that installation always go through first building a location agnostic "wheel" that cannot update LIBDIR to a proper location. Upstream packaging (debian, redhat, etc…) does not seems to adjust this variable themself. So it is safer to drop this dead code that pretend we could be doing something with it.
Pierre-Yves David authoredThis code is no longer used as the python packaging echo system evolved. This code was introduced in 10da5a1f25dd, with two feature in mind: - Mercurial may be installed into a non-standard location without having to set PYTHONPATH. - Multiple installations can use Mercurial from different locations. As a side effect it also provided performance improvement at a time where the `sys.path` could be greatly inflated from setuptools `.pth` files. And it also protected from incompatible directory within the `$PTYHONPATH` variable. Both of these benefit has faded overtime as `.pth` are less common and `$PYTHONPATH` is less used (as both where creating issue to more than just Mercurial). The initial motivation (easily install Mercurial anywhere), can now be handled by a new generation of tool like pipx or uv, so it is less of a concern. Regardless of all the above, the current code is no longer used. The evolution of python packaging means that installation always go through first building a location agnostic "wheel" that cannot update LIBDIR to a proper location. Upstream packaging (debian, redhat, etc…) does not seems to adjust this variable themself. So it is safer to drop this dead code that pretend we could be doing something with it.
hg 1.41 KiB
#!/usr/bin/env python3
#
# mercurial - scalable distributed SCM
#
# Copyright 2005-2007 Olivia Mackall <olivia@selenic.com>
#
# This software may be used and distributed according to the terms of the
# GNU General Public License version 2 or any later version.
from __future__ import annotations
import os
import sys
# Make `pip install --user ...` packages available to the official Windows
# build. Most py2 packaging installs directly into the system python
# environment, so no changes are necessary for other platforms. The Windows
# py2 package uses py2exe, which lacks a `site` module. Hardcode it according
# to the documentation.
if getattr(sys, 'frozen', None) == 'console_exe':
vi = sys.version_info
appdata = os.environ.get('APPDATA')
if appdata:
sys.path.append(
os.path.join(
appdata,
'Python',
'Python%d%d' % (vi[0], vi[1]),
'site-packages',
)
)
try:
from hgdemandimport import tracing
except ImportError:
sys.stderr.write(
"abort: couldn't find mercurial libraries in [%s]\n"
% ' '.join(sys.path)
)
sys.stderr.write("(check your install and PYTHONPATH)\n")
sys.exit(-1)
with tracing.log('hg script'):
# enable importing on demand to reduce startup time
import hgdemandimport
hgdemandimport.enable()
from mercurial import dispatch
dispatch.run()