batching: migrate basic noop batching into peer.peer
"Real" batching only makes sense for wirepeers, but it greatly
simplifies the clients of peer instances if they can be ignorant to
actual batching capabilities of that peer. By moving the
not-really-batched batching code into peer.peer, all peer instances
now work with the batching API, thus simplifying users.
This leaves a couple of name forwards in wirepeer.py. Originally I had
planned to clean those up, but it kind of unclarifies other bits of
code that want to use batching, so I think it makes sense for the
names to stay exposed by wireproto. Specifically, almost nothing is
currently aware of peer (see largefiles.proto for an example), so
making them be aware of the peer module *and* the wireproto module
seems like some abstraction leakage. I *think* the right long-term fix
would actually be to make wireproto an implementation detail that
clients wouldn't need to know about, but I don't really know what that
would entail at the moment.
As far as I'm aware, no clients of batching in third-party extensions
will need updating, which is nice icing.
APE=/sys/src/ape
<$APE/config
PYTHON=python
PYTHONBIN=/rc/bin
SH=ape/psh
PURE=--pure
ROOT=../..
# This is slightly underhanded; Plan 9 does not support GNU gettext nor
# does it support dynamically loaded extension modules. We work around
# this by calling build_py and build_scripts directly; this avoids
# additional platform hacks in setup.py.
build:VQ:
@{
cd $ROOT
$SH -c '$PYTHON setup.py $PURE build_py build_scripts'
}
clean:VQ:
@{
cd $ROOT
$SH -c '$PYTHON setup.py $PURE clean --all'
}
install:VQ: build
@{
cd $ROOT
$SH -c '$PYTHON setup.py $PURE install \
--install-scripts $PYTHONBIN \
--skip-build \
--force'
}
mkdir -p /lib/mercurial/hgrc.d
dircp hgrc.d /lib/mercurial/hgrc.d/
cp 9diff /rc/bin/