annotate contrib/dockerlib.sh @ 33800:f257943e47ab

repository: formalize peer interface with abstract base class

There are various interfaces for interacting with repositories
and peers. They form a contract for how one should interact with
a repo or peer object.

The contracts today aren't very well-defined or enforced. There
have been several bugs over the years where peers or repo types
have forgotten to implement certain methods. In addition, the
inheritance of some classes is wonky. For example, localrepository
doesn't inherit from an interface and the god-object nature of
that class means the repository interface isn't well-defined. Other
repository types inherit from localrepository then stub out
methods that don't make sense (e.g. statichttprepository
re-defining locking methods to fail fast).

Not having well-defined interfaces makes implementing alternate
storage backends, wire protocol transports, and repository types
difficult because it isn't clear what exactly needs to be
implemented.

This patch starts the process of attempting to establish more
order to the type system around repositories and peers.

Our first patch starts with a problem space that already has a
partial solution: peers. The peer.peerrepository class already
somewhat defines a peer interface. But it is missing a few things
and the total interface isn't well-defined because it is combined
with wireproto.wirepeer.

Our newly-established basepeer class uses the abc module to
declare an abstract base class with the properties and methods that
a generic peer must implement.

We create a new class that inherits from it. This class will hold
our other future abstract base classes / interfaces so we can expose
a unified base class/interface.

We don't yet use the new interface because subsequent additions
will break existing code without some refactoring first.

A new module (repository.py) was created to hold the interfaces.
I could have put things in peer.py. However, I have plans to
eventually add interfaces to define repository and storage types.
These almost certainly require a new module. And I figured having
all the interfaces live in one module makes sense. So I created
repository.py to be that future home.

Differential Revision: https://phab.mercurial-scm.org/D332

#!/bin/sh -eu

# This function exists to set up the DOCKER variable and verify that
# it's the binary we expect. It also verifies that the docker service
# is running on the system and we can talk to it.
function checkdocker() {
  if which docker.io >> /dev/null 2>&1 ; then
    DOCKER=docker.io
  elif which docker >> /dev/null 2>&1 ; then
    DOCKER=docker
  else
    echo "Error: docker must be installed"
    exit 1
  fi

  $DOCKER -h 2> /dev/null | grep -q Jansens && { echo "Error: $DOCKER is the Docking System Tray - install docker.io instead"; exit 1; }
  $DOCKER version | grep -Eq "^Client( version)?:" || { echo "Error: unexpected output from \"$DOCKER version\""; exit 1; }
  $DOCKER version | grep -Eq "^Server( version)?:" || { echo "Error: could not get docker server version - check it is running and your permissions"; exit 1; }
}

# Construct a container and leave its name in $CONTAINER for future use.
function initcontainer() {
  [ "$1" ] || { echo "Error: platform name must be specified"; exit 1; }

  DFILE="$ROOTDIR/contrib/docker/$1"
  [ -f "$DFILE" ] || { echo "Error: docker file $DFILE not found"; exit 1; }

  CONTAINER="hg-dockerrpm-$1"
  DBUILDUSER=build
  (
    cat $DFILE
    if [ $(uname) = "Darwin" ] ; then
        # The builder is using boot2docker on OS X, so we're going to
        # *guess* the uid of the user inside the VM that is actually
        # running docker. This is *very likely* to fail at some point.
        echo RUN useradd $DBUILDUSER -u 1000
    else
        echo RUN groupadd $DBUILDUSER -g `id -g` -o
        echo RUN useradd $DBUILDUSER -u `id -u` -g $DBUILDUSER -o
    fi
  ) | $DOCKER build --build-arg http_proxy --build-arg https_proxy --tag $CONTAINER -
}