( )⚙ D332 repository: formalize peer interface with abstract base class

This is an archive of the discontinued Mercurial Phabricator instance.

Differential D332

repository: formalize peer interface with abstract base class
ClosedPublic

Authored by indygreg on Aug 11 2017, 12:20 AM.

Details

Reviewers
None
Group Reviewers
hg-reviewers
Commits
rHGf257943e47ab: repository: formalize peer interface with abstract base class
Summary

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.

Diff Detail

Repository
rHG Mercurial
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

indygreg created this revision.Aug 11 2017, 12:20 AM
durin42 added a subscriber: durin42.Aug 11 2017, 2:23 PM
durin42 added inline comments.
mercurial/repository.py
30

Nit: shouldn't this typically be a connection string with any credentials potentially redacted?

44

In what cases would a _basepeer not be a peer? What value does this part of the interface provide?

indygreg added inline comments.Aug 11 2017, 8:21 PM
mercurial/repository.py
44

TBH, I'm not sure why this exists. I cargo culted it from the existing peer API.

Once this series is accepted, I'd like to make some BC changes to the interface. This method is on the chopping block. Another is close(). AFAICT we don't call close() consistently and I'd like to switch things to context managers. But that's for another day...

indygreg added inline comments.Aug 13 2017, 1:55 PM
mercurial/repository.py
30

I looked at the code and today we're exposing the raw URL, before any redaction. This raw URL is then fed into things like hooks.

We should probably fix this by cleaning up existing usage and making the purpose of the attribute more well-defined. But I think it is outside the scope of this series. I'll add an inline TODO to track it.

indygreg updated this revision to Diff 847.Aug 13 2017, 2:18 PM
Closed by commit rHGf257943e47ab: repository: formalize peer interface with abstract base class (authored by indygreg). · Explain WhyAug 15 2017, 1:50 PM
This revision was automatically updated to reflect the committed changes.

Revision Contents
Changeset List

PathPackages
AMmercurial/repository.py (71 lines)

Diff 931

mercurial/repository.py

  • This file was added.
# repository.py - Interfaces and base classes for repositories and peers.
#
# Copyright 2017 Gregory Szorc <gregory.szorc@gmail.com>
#
# This software may be used and distributed according to the terms of the
# GNU General Public License version 2 or any later version.
from __future__ import absolute_import
import abc
class _basepeer(object):
"""Represents a "connection" to a repository.
This is the base interface for representing a connection to a repository.
It holds basic properties and methods applicable to all peer types.
This is not a complete interface definition and should not be used
outside of this module.
"""
__metaclass__ = abc.ABCMeta
@abc.abstractproperty
def ui(self):
"""ui.ui instance."""
@abc.abstractmethod
def url(self):
"""Returns a URL string representing this peer.
durin42Unsubmitted
Not Done

Nit: shouldn't this typically be a connection string with any credentials potentially redacted?

durin42: Nit: shouldn't this typically be a connection string with any credentials potentially redacted?
indygregAuthorUnsubmitted
Not Done

I looked at the code and today we're exposing the raw URL, before any redaction. This raw URL is then fed into things like hooks.

We should probably fix this by cleaning up existing usage and making the purpose of the attribute more well-defined. But I think it is outside the scope of this series. I'll add an inline TODO to track it.

indygreg: I looked at the code and today we're exposing the raw URL, before any redaction. This raw URL…
Currently, implementations expose the raw URL used to construct the
instance. It may contain credentials as part of the URL. The
expectations of the value aren't well-defined and this could lead to
data leakage.
TODO audit/clean consumers and more clearly define the contents of this
value.
"""
@abc.abstractmethod
def local(self):
"""Returns a local repository instance.
If the peer represents a local repository, returns an object that
durin42Unsubmitted
Not Done

In what cases would a _basepeer not be a peer? What value does this part of the interface provide?

durin42: In what cases would a _basepeer not be a peer? What value does this part of the interface…
indygregAuthorUnsubmitted
Not Done

TBH, I'm not sure why this exists. I cargo culted it from the existing peer API.

Once this series is accepted, I'd like to make some BC changes to the interface. This method is on the chopping block. Another is close(). AFAICT we don't call close() consistently and I'd like to switch things to context managers. But that's for another day...

indygreg: TBH, I'm not sure why this exists. I cargo culted it from the existing peer API. Once this…
can be used to interface with it. Otherwise returns ``None``.
"""
@abc.abstractmethod
def peer(self):
"""Returns an object conforming to this interface.
Most implementations will ``return self``.
"""
@abc.abstractmethod
def canpush(self):
"""Returns a boolean indicating if this peer can be pushed to."""
@abc.abstractmethod
def close(self):
"""Close the connection to this peer.
This is called when the peer will no longer be used. Resources
associated with the peer should be cleaned up.
"""
class peer(_basepeer):
"""Unified interface and base class for peer repositories.
All peer instances must inherit from this class.
"""