[BUG] patch.py not portable to windows
aaron.bentley at utoronto.ca
Fri Jul 1 20:18:35 BST 2005
-----BEGIN PGP SIGNED MESSAGE-----
John A Meinel wrote:
> Anyway, inside of that code, he spawns patch in order to apply patches
> to files. Unfortunately, he uses popen2.Popen3() which does not exist on
> (patch may not exist on windows, but I'm not worrying about
> that case yet).
> This is one of the motivations to move to using subprocess since it
> really cleans up process spawning.
It's unfortunate that we can't just bundle subprocess as we do
ElementTree, but the need to compile a C module on Windows kills that.
Canonical's using a library called 'gnarly' for process spawning that's
all-Python, and supposed to be subprocess-compatible, so that might work.
> In the long term, it would be nice to switch to perhaps a python
> implementation of patch, something that could keep everything in memory,
> rather than having to write out a bunch of temporary files. Right now,
> you have to decompress the store data, write that to a file, then spawn
> patch and pipe in the changes and create a new file, the read that back
> in, and delete the other files.
It's rather shocking that Python can produce unified diffs, but can't
apply them, eh? (Actually, it's not producing them properly, either.)
I can kinda see why, though. People would expect the same behavior for
fuzzy patch-application, which could be tricky to get right.
> Is there interest in writing a built-in patch? It wouldn't have to be a
> super-fancy one, since most of the use cases are for exact patching. Any
> fuzzy patching is generally done by the merge code (and diff3 or patch).
> It seems like you could write a unified diff patcher without too many
> lines of python. It probably wouldn't try as hard as patch might.
If you're interested, you might want to use my unified diff parser,
which is included in bzrtools. The issue I see is diff3 itself uses
diff, so unless we get rid of diff3, we need diff, and patch usually
comes with it. Replacing diff3 in Python would be no mean feat.
> I suppose we need to come up with some sort of consensus if we want to
> have things work under windows. Even if we just recommend installing
> some version if diff & patch, we still can't use the Popen3/Popen4
> classes in popen2.
Sure. I'll look for an alternative way of invoking it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar