I'm also not super crazy about abusing extras for this. But it is the best compromise considering the "better" solutions require a lot more effort and thought. At some point, I would like Mercurial's storage and wire protocol to grow official APIs for storing and exchanging arbitrary data outside the current storage primitives. Maybe we can shoehorn storage into revlogs in .hg/store/meta. I dunno. Feels like sprint material to me.

I still need to look at this commit in detail, but any commit that alters the on-disk or on-network behavior of Mercurial should ideally be accompanied by a docs change to mercurial/help/internals. I say ideally because some things still aren't documented. But repo requirements are. Please follow up with a patch to document the new requirement in mercurial/help/internals/requirements.txt.

Ideally the new part would be documented in internals.bundle2. But other narrow parts aren't documented, so maybe we can hold off...

+1 for feature. Needs some minor work to get review.

Do you have performance numbers to share? Substantial wins would definitely pique my interest :)

An idea to consider (which may have been proposed already) is to write a *no copy metadata* entry into extras when writing copy metadata to the changelog. If we did things this way, a new client could know definitively that no copy metadata is available and to not fall back to reading from the filelogs. I haven't fully thought this through, but that should provide better compatibility between older and newer clients. Obviously the tradeoff is you could have a mixed repo (some changesets wouldn't have copy metadata in changelog) and you would need to duplicate copy metadata across changelog and filelogs to maintain compatibility. Something to contemplate...

I support experimenting with putting copy metadata in the changelog. And the patches before this one did a lot of work to allow copy metadata to be read from alternate sources, which is great, since it can allow flexibility in the future (think copy caches, copy modifications outside of a commit, etc).

This patch is backwards incompatible over the wire protocol.

In D6258#91055, @durin42 wrote:

Argh. This change appears to be wrong (!) so I'm going to drop it.

In D6164#90074, @durin42 wrote:

In D6164#90073, @indygreg wrote:

I would prefer you fix them :)

Okay, then what should we call it? --extra-packages-script since that's what it's for?

I would prefer you fix them :)

Was a newer version of this patch with the requested changes going to be uploaded? It's weird to see additional patches in the series without this one updated...

In D6164#89915, @durin42 wrote:

In D6164#89914, @indygreg wrote:

In D6164#89913, @durin42 wrote:

How about we add an argument to define the path(s) to the pip requirements file(s) to use? By default, it can use the requirements.txt in the repo. Would that solve your use case?

No, because I have some stuff which (out of tragic necessity at the moment) isn't pip installable, and I have to install it into the virtualenv by banging some rocks together. :(

In D6164#89913, @durin42 wrote:

In D6142#89492, @mharbison72 wrote:

I don't know anything about PowerShell or AWS, but this series looks nice for making Windows easier to deal with.
What was the problem with python3 tests? I've been able to run them locally (though a bunch fail with py3 issues).

I like the flexibility. But I'm not super keen about the interface here. Using a script to inject custom options seems like it could be useful. But as it is currently implemented, the script simply prints out \0 delimited package names. So one UI wart is --extra-prebuild-script being a somewhat generic name but that script only emits package names. --extra-packages-script would be a better name.

According to a private email, things were inconsistent because py2exe didn't (doesn't?) support bundling DLLs in the zip several years ago, so things *had* to be a certain way.