python3, hgloader, and extensions

[Ludovic Chabant]

Thanks for the reply!

> AFAIK, that's by-design thing. What the hgloader does is a bunch
> of weird hacks only valid for our codebase, which we'll eventually
> get rid of.

Then either the design is wrong, or the code is wrong.

First, like I said, depending on *how* you import an extension, it will
or will not run the hgloader. That's extremely confusing, and has lost
me a few days of investigations and head scratching. The behaviour
should be the same whether you use a pip-installed, PYTHONPATH-located,
or specific location import.

Second, the hgloader specifically looks for (among other things)
`hgext3d.*` and `hgext.*`. If we didn't want to run it for 3rd party
extensions, it surely is a bug that it checks for `hgext3rd`. Plus, when
you import an extension directly by path, it hardcodes its module name
to `hgext.<foo>` so technically the hgloader _would_ process it (it
doesn't right now but it's really by pure luck I think).

So if the hgloader is _not_ supposed to run on non-core extensions, we
should remove the check for `hgext3rd` at least, and, as much as
possible, prevent it from running even when you import an extension
that's in your PYTHONPATH. At that point, I think the easiest way would
be to change the hgloader to check for the location of the source file
and see if it falls inside the core mercurial install path or somewhere
else. What do you think?


> You can instead use contrib/byteify-strings.py to apply some of the
> changes the hgloader would do.

Yeah I orginally did that. It makes your code ugly, and it's only even
remotely acceptable as an "upgrade" tool. When you actually write a
*new* extension (or edit an existing one to add a new command or
something), it's totally not natural to write byte strings everywhere.

Is the plan to run byteify-strings.py on the mercurial codebase then?