Extending extension lookups

Pierre-Yves David pierre-yves.david at ens-lyon.org
Tue Jan 19 13:34:24 CST 2016



On 01/19/2016 08:03 AM, Augie Fackler wrote:
> On Sun, Jan 17, 2016 at 08:10:08PM -0600, Matt Mackall wrote:
>> On Wed, 2016-01-13 at 18:58 +0000, Martijn Pieters wrote:
>>> I was asked by Pierre-Yves to create a proposal to support more than
>>> just an hgext namespace for extensions bundled with Mercurial, to help
>>> facilitate experimental extensions (see
>>> https://www.mercurial-scm.org/wiki/ExperimentalExtensionsPlan).
>>
>> I guess I don't see what the advantage is here over simply adding the
>> "(EXPERIMENTAL)" flag to the top of the docs. Commands and extensions marked
>> experimental are hidden from the help today (see the chg extension) and we are
>> free to have whatever stability policy we want with them.
>>
>> I guess if people find extensions by poking around on disk, they
>> might be slightly more prone to not realizing a given extension is
>> experimental if it's not in a separate directory.. but I must
>> confess I have pretty limited sympathy for people who poke around in
>> source code without looking at either the source or the docs.
>>
>> One minor downside with your plan that doesn't exist with the status quo is that
>> we'll eventually have to move the code if we decide to make it official.
>>
>>> While I'm at it, I also want to look at where extensions (3rd party or
>>> core) are to be installed. Mercurial extensions are currently expected
>>> to be installed in the standard Python site-packages directory. Is
>>> there any interest in moving extension out to a new, separate
>>> location? With a little work (like a provided hgsetup.py module),
>>> installation of extensions can still be done with the standard Python
>>> tools. Mercurial would add that new location to the Python module
>>> search path on startup and loading extensions would not have to
>>> otherwise change. But at the same time, you then guarantee that
>>> Mercurial extensions can't be confused with 'regular' Python
>>> libraries. Is there any interest in doing this?
>>
>> I am interested in being able to have extensions in a standard place in my home
>> directory that hg can automatically find. In particular, I'd like it to be able
>> to search in ~/src/foobar/hgext/foobar.py without having to run anything (except
>> maybe configure my extension path to ~/src/). Then all third-party modules I
>> grab off Bitbucket with a reasonable directory layout can just be cloned into a
>> directory together.
>
> I think we might be able to do this with some sort of entry_points
> thing in setuptools. Should I look further?

I've a strong opinion against using setuptools,

First, setuptools is just plain broken. The .eggs formats and mechanism 
used by default for setuptools we care about, is just plain broken. It 
change the semantic around the python import order to make it just broken.

Second, this eggs mechanims also inflates the sys.path (place to search 
for module) is a O(installed package) way, leading any imports to make a 
massive amount of useless lookup in zip file.
The brokenness in import order is not acceptable. The import slowdown is 
a significant issue for Mercurial performances.

The two reasons above are already sufficient for me to want to stay away 
from setup tools until its the very recent version.

Finally, the entry points concept you are pointing at is nice on paper, 
but again the implementation is not appealing for us. Entry point are 
stored in the .egginfo meta data file. When you request for entry point, 
setuptools will have to search for all .egginfo ever installed on your 
system, parse all of them, extract the entry point data and filter the 
one relevant to Mercurial. I think we can do much better than a process 
that involves O(Installed package) file parsing.


Yes, I'm aware (and happy) that a group of sensible people took care of 
improving the situation a lot and latest version of python packaging 
improved a lot, fixing some of the brokeness (eg: no more eggs by 
default if I'm not mistaken). However:

a) We are supporting old version of python were these improvement will 
not exists,

b) Some structural issues (entry point requiring to parse all meta data 
for all packages ever installed) still exists.

So, from my perspective, anything involving setuptools is off the table.

Cheers,

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list