Commit Graph

5 Commits

Author SHA1 Message Date
Lukasz Langa
dfda82e492 Upgrade to 18.5b1
Summary: Mostly empty lines removed and added.  A few bugfixes on excessive line splitting.

Reviewed By: quark-zju

Differential Revision: D8199128

fbshipit-source-id: 90c1616061bfd7cfbba0b75f03f89683340374d5
2018-05-30 02:23:58 -07:00
Jun Wu
584656dff3 codemod: join the auto-formatter party
Summary:
Turned on the auto formatter. Ran `arc lint --apply-patches --take BLACK **/*.py`.
Then run `arc lint` again so some other autofixers like spellchecker etc. looked
at the code base. Manually accept the changes whenever they make sense, or use
a workaround (ex. changing "dict()" to "dict constructor") where autofix is false
positive. Disabled linters on files that are hard (i18n/polib.py) to fix, or less
interesting to fix (hgsubversion tests), or cannot be fixed without breaking
OSS build (FBPYTHON4).

Conflicted linters (test-check-module-imports.t, part of test-check-code.t,
test-check-pyflakes.t) are removed or disabled.

Duplicated linters (test-check-pyflakes.t, test-check-pylint.t) are removed.

An issue of the auto-formatter is lines are no longer guarnateed to be <= 80
chars. But that seems less important comparing with the benefit auto-formatter
provides.

As we're here, also remove test-check-py3-compat.t, as it is currently broken
if `PYTHON3=/bin/python3` is set.

Reviewed By: wez, phillco, simpkins, pkaush, singhsrb

Differential Revision: D8173629

fbshipit-source-id: 90e248ae0c5e6eaadbe25520a6ee42d32005621b
2018-05-25 22:17:29 -07:00
Gregory Szorc
1ffc45ea51 repository: implement generic capability methods on peer class
These methods are part of the peer interface, are generic, and can
be implemented in terms of other members of the peer interface. So we
implement them on the peer base class as a convenience.

The implementation is essentially copied from peer.py. The code
in peer.py will eventually be deleted.

Differential Revision: https://phab.mercurial-scm.org/D334
2017-08-06 16:47:25 -07:00
Gregory Szorc
1e5a17ee62 repository: formalize wire protocol interface
There are a well-defined set of commands constituting the wire
protocol. Interaction with these and methods for calling them in
batches are exposed via methods on peer instances.

Let's formalize support for these features in abstract classes.

The command parts come from the existing wireproto.wirepeer class.
The batch methods come from peer.peerrepository.

Ample documentation has been added as part of defining the interfaces.

# no-check-commit

Differential Revision: https://phab.mercurial-scm.org/D333
2017-08-13 11:04:42 -07:00
Gregory Szorc
99b48bdf1a 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
2017-08-13 10:58:48 -07:00