upstream/mercurial-mirror Files · mercurial/help/urls.txt

mercurial: implement import hook for handling C/Python modules...

mercurial: implement import hook for handling C/Python modules There are a handful of modules that have both pure Python and C extension implementations. Currently, setup.py copies files from mercurial/pure/*.py to mercurial/ during the install process if C extensions are not available. This way, "import mercurial.X" will work whether C extensions are available or not. This approach has a few drawbacks. First, there aren't run-time checks verifying the C extensions are loaded when they should be. This could lead to accidental use of the slower pure Python modules. Second, the C extensions aren't compatible with PyPy and running Mercurial with PyPy requires installing Mercurial - you can't run ./hg from a source checkout. This makes developing while running PyPy somewhat difficult. This patch implements a PEP-302 import hook for finding and loading the modules with both C and Python implementations. When a module with dual implementations is requested for import, its import is handled by our import hook. The importer has a mechanism that controls what types of modules we allow to load. We call this loading behavior the "module load policy." There are 3 settings: * Only load C extensions * Only load pure Python * Try to load C and fall back to Python An environment variable allows overriding this policy at run time. This is mainly useful for developers and for performing actions against the source checkout (such as installing), which require overriding the default (strict) policy about requiring C extensions. The default mode for now is to allow both. This isn't proper and is technically backwards incompatible. However, it is necessary to implement a sane patch series that doesn't break the world during future bisections. The behavior will be corrected in future patch. We choose the main mercurial/__init__.py module for this code out of necessity: in a future world, if the custom module importer isn't registered, we'll fail to find/import certain modules when running from a pure installation. Without the magical import-time side-effects, *any* importer of mercurial.* modules would be required to call a function to register our importer. I'm not a fan of import time side effects and I initially attempted to do this. However, I was foiled by our own test harness, which has numerous `python` invoked scripts that "import mercurial" and fail because the importer isn't registered. Realizing this problem is probably present in random Python scripts that have been written over the years, I decided that sacrificing purity for backwards compatibility is necessary. Plus, if you are programming Python, "import" should probably "just work." It's worth noting that now that we have a custom module loader, it would be possible to hook up demand module proxies at this level instead of replacing __import__. We leave this work for another time, if it's even desired. This patch breaks importing in environments where Mercurial modules are loaded from a zip file (such as py2exe distributions). This will be addressed in a subsequent patch.

Mike Williams - - Load All Authors

File last commit:

r19197:01d68fb0 stable


                r27220:4374d819

default

Download file

             urls.txt
        
                    66 lines
            
             | 2.3 KiB
            
                | text/plain
            
             |
                TextLexer

/ mercurial / help / urls.txt

History | Source | Raw |Copy content |Copy permalink

Dan Villiom Podlaski Christiansen setup: install translation files as package data...	r9999	Valid URLs are of the form::

		local/filesystem/path[#revision]
Mads Kiilerich help: Backed out changeset e99facd2cd2a, description of file urls...	r15533	file://local/filesystem/path[#revision]
Dan Villiom Podlaski Christiansen setup: install translation files as package data...	r9999	http://[user[:pass]@]host[:port]/[path][#revision]
		https://[user[:pass]@]host[:port]/[path][#revision]
Matt Mackall help: ssh urls don't allow passwords	r13304	ssh://[user@]host[:port]/[path][#revision]
Dan Villiom Podlaski Christiansen setup: install translation files as package data...	r9999
		Paths in the local filesystem can either point to Mercurial
Mike Williams help: stop documentation markup appearing in generated help...	r19197	repositories or to bundle files (as created by :hg:`bundle` or
		:hg:`incoming --bundle`). See also :hg:`help paths`.
Dan Villiom Podlaski Christiansen setup: install translation files as package data...	r9999
		An optional identifier after # indicates a particular branch, tag, or
Martin Geisler Use hg role in help strings	r10973	changeset to use from the remote repository. See also :hg:`help
		revisions`.
Dan Villiom Podlaski Christiansen setup: install translation files as package data...	r9999
		Some features, such as pushing to http:// and https:// URLs are only
		possible if the feature is explicitly enabled on the remote Mercurial
		server.

Mads Kiilerich doc: clarify that https cert verification requires web.cacerts	r12593	Note that the security of HTTPS URLs depends on proper configuration of
		web.cacerts.

Dan Villiom Podlaski Christiansen setup: install translation files as package data...	r9999	Some notes about using SSH with Mercurial:

		- SSH requires an accessible shell account on the destination machine
		and a copy of hg in the remote path or specified with as remotecmd.
		- path is relative to the remote user's home directory by default. Use
		an extra slash at the start of a path to specify an absolute path::

		ssh://example.com//tmp/repository

		- Mercurial doesn't use its own compression via SSH; the right thing
		to do is to configure it in your ~/.ssh/config, e.g.::

		Host *.mylocalnetwork.example.com
		Compression no
		Host *
		Compression yes

Brodie Rao help: refer to user configuration file more consistently...	r12083	Alternatively specify "ssh -C" as your ssh command in your
		configuration file or with the --ssh command line option.
Dan Villiom Podlaski Christiansen setup: install translation files as package data...	r9999
Brodie Rao help: refer to user configuration file more consistently...	r12083	These URLs can all be stored in your configuration file with path
		aliases under the [paths] section like so::
Dan Villiom Podlaski Christiansen setup: install translation files as package data...	r9999
		[paths]
		alias1 = URL1
		alias2 = URL2
		...

		You can then use the alias for any command that uses a URL (for
Martin Geisler Use hg role in help strings	r10973	example :hg:`pull alias1` will be treated as :hg:`pull URL1`).
Dan Villiom Podlaski Christiansen setup: install translation files as package data...	r9999
		Two path aliases are special because they are used as defaults when
		you do not provide the URL to a command:

		default:
		When you create a repository with hg clone, the clone command saves
		the location of the source repository as the new repository's
		'default' path. This is then used when you omit path from push- and
		pull-like commands (including incoming and outgoing).

		default-push:
		The push command will look for a path named 'default-push', and
		prefer it over 'default' if both are defined.

	Site-wide shortcuts
/	Use quick search box
g h	Goto home page
g g	Goto my private gists page
g G	Goto my public gists page
g 0-9	Goto bookmarked items from 0-9
n r	New repository page
n g	New gist page

	Repositories
g s	Goto summary page
g c	Goto changelog page
g f	Goto files page
g F	Goto files page with file search activated
g p	Goto pull requests page
g o	Goto repository settings
g O	Goto repository access permissions settings
t s	Toggle sidebar on some pages