Possibly splitting matchers into its own package?

[cyli]

I've found myself using matchers a lot for non-testing related purposes. It's a very clear way of describing an object, and seems more so than writing your own callable.

It also seems particularly useful as an easy way to write validators for expected JSON input, etc., if you are using it for something small and you don't want to write a full JSON schema for instance.

It might also be useful for something like the attrs library, for specifying custom validators.

The mismatch reporting is also pretty great.

It seems like a pretty useful tool for people to use, but it might get more visibility if detached from testtools. Right now the documentation is part of the testtools documentation, and people might not learn about it unless they're looking for a testing utility.

As it seems like it can stand on its own, maybe splitting it off into its own package and documentation/example usages outside of testing might encourage more usage and contributions?

[radix]

👍

[jml]

I'm in favour, especially if the package makes it easy to use in regular &
trial tests.

Matchers are mostly lifeless's thing, so will wait for his approval. (Also,
would welcome it if someone else would do the required work).

On Thu, 18 Jun 2015 at 00:18 Christopher Armstrong [email protected]
wrote:

[image: 👍]

—
Reply to this email directly or view it on GitHub
#145 (comment)
.

[radix]

While thinking about this ticket, I happened across three other projects that do things very similar to testtools.matchers, as separate libraries:

• https://pypi.python.org/pypi/schema
• https://pypi.python.org/pypi/voluptuous
• https://pypi.python.org/pypi/validino

with varying support for producing useful human-oriented mismatch messages.

I don't know what the testtools developers may gain from this information, I'm just making it available.

[radix]

@jml one thing in particular that makes testtools matchers useful in contexts other than testtools-based unit tests is this class: https://github.com/rackerlabs/otter/blob/bbb03e94464c7c66df7000a7f48a73a880cb3fe0/otter/test/utils.py#L46

This wraps any matcher in an object supporting __eq__, so you can just use assertEqual or assert ... == ... with matchers. It provides a __repr__ that shows the latest mismatch.

[jml]

@radix there's also hamcrest.

That class is a great idea. It should be a patch to some project.

[rbtcollins]

I'm fine with it being split out. We created matchers in the first place because hamcrest seemed so unpythonic. I think the API is pretty settled now though.

[cyli]

So would the work involved be:

1. Creating a new "matchers" repo in this org and moving everything over (docs, the matchers module)
2. Doing a setup.py and read-the-docs page for it
3. Publishing matchers to pypi
4. Submitting a new PR to testtools to just export everything the matchers package exports in the testtool.matchers module (to keep compatibility? Maybe with a deprecation warning?)

[rbtcollins]

Yes; I think filter-branch would be appropriate - preserve the history of the matcher repo; then commits on top of that to reorganise the namespace etc.

I don't think we should deprecate the location straight off - give it time to bake a little.

If you can prep a filter-branch + some cleanups on top somewhere, I'll make the new repo and register it with pypi and rtd and pull it in here (after mk1 eyeball review ;)).

[cyli]

@rbtcollins - sounds good - I can just make as a personal repo sometime this weekend, and either we can transfer ownership or push to a new location. Any suggestions for a name?

[jml]

@cyli The least terrible name I can think of is "matcherz". Other suggestions welcome.

[rkawala]

Just curious: did @cyli ever get around to pulling out a separate package for the matchers? Boy, that'd be really useful to me right about now! :) If so, does anyone have the URL for the repo?