kgb 7.0: Pytest, Python 3.10, and more

kgb 7.0 has been released with a handful of new features:

  • Python 3.10 support
  • Support for pytest, and other non-unittest-based test frameworks
  • Snake-case and standalone assertion methods
  • Workarounds for spying on methods with poorly-implemented decorators

It also drops official support for Python 2.6 and 3.4-3.5 (though these should still work for now, if you need them).

pytest

kgb now provides a spy_agency fixture for pytest unit tests. This will set up a SpyAgency for you, letting you spy on functions and assert calls. For example:

def test_doomsday_device(spy_agency):
    device = DoomsdayDevice()
    spy_agency.spy_on(device.destroy_reality, call_original=False)

    device.trigger_the_event()

    spy_agency.assert_spy_called(device.destroy_reality)

The SpyAgency will be managed for the lifetime of the test, removing spies upon completion.

Snake-case and standalone assertion methods

We’ve provided snake_case versions of all the assertion methods, making for more natural tests. For instance, you can use assert_spy_called_with() instead of assertSpyCalledWith(). The old camelCase versions will continue to exist, though.

You can also call assertion methods without needing to mix in a SpyAgency into your test. Just import from kgb.asserts. This is useful if you have a need to spy on methods and assert them within non-unit test code, or without access to a SpyAgency. For example:

from kgb.asserts import assert_spy_called_with

def check_connection_state(api_connection):
    assert_spy_called_with(api_connection.make_request,
                           url='https://middleman.zyx',
                           method='POST')

Workarounds for bad decorators

Before, if you were trying to spy on a method (particularly unbound methods) wrapped in a decorator, and that decorator didn’t preserve the function’s original name, you’d hit an error looking up the method.

You can now work around this by passing the original function name when setting up a spy. For example:

def bad_decorator(func):
    def _wrap(*args, **kwargs):
        return func(*args, **kwargs)

    return _wrap

class BadClass:
    @bad_decorator
    def good_func(self):
        return 42

def test_good_func(spy_agency):
    spy_agency.spy_on(BadClass.good_func,
                      owner=BadClass,
                      func_name='good_func')

kgb will try to detect when you need this and emit a warning during the test.

Get started with kgb 7.0

See the release notes for the full list of changes.

You can install kgb today through pip:

$ pip install -U kgb

Visit our kgb documentation to see how to use kgb in your projects.

Read More

kgb 6.1: New spy operations, with nesting

kgb 6.1 has been released, featuring some new spy operations and enhancements to existing ones.

kgb is our Python unit test library for crafting function spies, making it easy to check on the calls made during a test or to override their behavior, in ways not possible with Python’s mock.

New spy operations

Two new spy operations, kgb.SpyOpReturnInOrder and kgb.SpyOpRaiseInOrder, have been added. These work like a combination of kgb.SpyOpReturn/kgb.SpyOpRaise and kgb.SpyOpMatchInOrder. Each takes a list of results, and each call will receive the next result in the list, making it really easy to build tests that, somewhere, involve repeated calls to some function.

For example:

spy_on(our_agent.get_identity, op=kgb.SpyOpReturnInOrder([
    'nobody...',
    'who?',
    'not telling...',
]))

spy_on(pen.emit_poison, op=kgb.SpyOpRaiseInOrder([
    PoisonEmptyError(),
    Kaboom(),
    MissingPenError(),
]))

Nesting spy operations

The kgb.SpyOpMatchInOrder and kgb.SpyOpMatchAny operations can now nest other spy operations, which simplifies returning or raising values, and can even allow for more advanced interactions with a spy.

The call definitions passed now accept an 'op' key pointing to a spy operation instance, which will be invoked if a call matches.

For example:

spy_on(lockbox.enter_code, op=kgb.SpyOpMatchInOrder([
    {
        'args': (42, 42, 42, 42, 42, 42),
        'op': kgb.SpyOpRaise(Kaboom()),
        'call_original': True,
    },
]))

Get started with 6.1

See the release notes for the full list of changes.

You can install kgb today through pip:

$ pip install -U kgb

Visit our kgb documentation to see how to use kgb in your projects.

Read More

Djblets 2.2.1: Fixes for extension packaging

Djblets 2.2.1 has been released, fixing an issue with building extension packages.

If a project (say, Review Board) made use of build_pipeline_settings() in its settings.py, it could cause problems when trying to build extension packages.

This happened because this function validates some paths that may not exist yet at that stage in the packaging process. This release temporarily disables path validation at this stage.

See the release notes for the full changes.

Read More

beanbag-docutils 1.8: Sphinx 3 and Django 3

beanbag-docutils is a set of extensions to the Sphinx ReStructuredText-based documentation system used by our products to help generate better documentation. Amongst other enhancements, it provides:

  • A parser for the Beanbag docstring format, a variation on the Google docstring format, which we use for Python and JavaScript documentation
  • Enhancements for Sphinx’s intersphinx system to provide per-page intersphinx resolution options (useful for pages, such as release notes, that need to link to different versions of the same docs, such as Django or Python)
  • Enhancements to ReStructuredText references to let a reference name span lines (useful for long Python/JavaScript module/class names)
  • Linking code references to GitHub documentation
  • High-DPI image embedding
  • A role for HTTP status codes

Today’s release of beanbag-docutils 1.8 features:

  • Compatibility with Sphinx 1.7 through the latest 3.x (as of this writing, 3.5.1)
  • Compatibility with Django 3.x (when using the django_utils extension)
  • New documentation, which we’ll be expanding over time.

See the release notes for the full list of changes.

Read More

Djblets 2.0: Now supporting Python 3 and Django 1.11

We quietly released Djblets 2.0 a few days ago, now supporting Python 3 and Django 1.11. This is a major milestone for Djblets, as we’re finally leaving behind the formerly-necessary legacy version of Django 1.6, with our sights set on future major releases keeping up with the latest Django has to offer.

What’s Djblets?

Djblets is an add-on package for Django that provides a great deal of additions useful for building large, extensible web applications, like Review Board. This includes:

  • Dynamic site configuration and settings
  • Extension support for applications
  • Base for designing REST APIs
  • Consent-based, privacy-first foundation for features
  • Feature flags with extensible backends
  • Avatar rendering and extensible backends
  • Datagrid UIs
  • Database fields for Base64 content, atomic counters, and more
  • Mail sending additions supporting DMARC and smart From/Sender header spoofing
  • Rate limiting
  • Unit testing improvements

And plenty more.

What’s New?

Quite a lot!

  • Support for Python 2.7 and 3.6 through 3.9
  • Support for Django 1.11 (the last version to support Python 2.7)
  • New configuration forms CSS/JavaScript component library
  • New UIs for managing extensions and integrations
  • Extensions can now provide schema changes as evolutions or Django’s migrations
  • A new form widget for selecting related objects (for populating a ForeignKey or ManyToManyField)
  • Utility property for defining aliases (with optional conversion and/or deprecation warnings) to other properties
  • Utility property for defining properties requiring certain data types, with validation
  • Improved way of defining types for REST API fields
  • New template tags and filters for working with object data and custom template variables

Plus lots of new features and minor bug fixes.

The full list is in the release notes.

See the documentation or start using Djblets in your own project!

Read More

RBTools 2.0: Ready for Review Board 4.0

RBTools 2.0 is out, bringing compatibility improvements and new features for all users. The biggest improvement is the support for Review Board 4.0’s upcoming multi-commit review requests.

Multi-Commit Review Requests

Review Board 4.0 beta 1 is coming in the next few weeks, and with RBTools 2.0, developers will be able to post a series of commits to a review request so that they can be reviewed individually or as one squashed change, depending on what the reviewer chooses to do.

Those changes can also be landed, preserving their history or squashing them back into a single commit.

To stay with the old behavior and squash the commits before posting to a review request, you can pass –squash to rbt post or rbt land (or set SQUASH_HISTORY = True or LAND_SQUASH = True, respectively, in .reviewboardrc).

This is available for both Git and Mercurial, and will require Review Board 4.0.

RBCommons users will receive multi-commit review request support in 2021.

Custom Certificate Authorities

If your Review Board server uses a self-signed certificate backed by an in-house Certificate Authority, you can now configure RBTools to recognize it through the --ca-certs, --client-key, and --client-cert options (or CA_CERTS, CLIENT_KEY, and CLIENT_CERT in .reviewboardrc).

Easier Repository Setup

rbt setup-repo has been redesigned to better help people configure their local repositories to connect to Review Board. It offers a more helpful guided setup, making it easier to find the right repository and generate your .reviewboardrc file.

Default Branches in Git

RBTools now understands the init.defaultBranch configuration for Git, helping you transition your primary branch from master to something like main.

Better Mercurial Integration

Compatibility issues are fixed, repository detection is faster, and custom scripts can benefit from performance improvements by connecting RBTools to the Mercurial command server.

And Better Perforce Integration

RBTools can work with a wider mix of configurations utilizing SSL and brokers.

There’s also a new reviewboard.repository_name Perforce counter that can tie a depot to a Review Board repository, which can be used if .reviewboardrc isn’t an option.

Plus…

  • Variety of improvements for Python 3 compatibility (including support for Python 3.9).
  • Additional Git arguments for fine-tuning rename detection.
  • Custom formatting for rbt status, which is useful for scripting.
  • rbt land and rbt patch now accept a review request URL, instead of just an ID.
  • rbt patch can print a patch from a review request without needing a local copy of the repository.

See the release notes for more information, or download RBTools 2.0 today.

Read More

New Release: Django Evolution 2.1

Just a few months ago, we released Django Evolution 2.0, the first release to support database upgrades using both Django’s migrations and our own evolutions.

Django Evolution 2.1 builds on this by introducing enhanced dependency management for evolutions and migrations. Now, an evolution (or its app) can specify other evolutions or migrations that must be applied either before or after.

Django applications that make use of swappable models can benefit from this, as an evolution defining that model can now be applied before a migration that requires it.

See the guide on adding dependencies to learn more.

Other highlights include:

  • Compatibility with Python 3.9
  • Workarounds for MySQL/MariaDB bugs in Django 1.8 through 1.10
  • Enhanced transaction management, providing safer upgrades and recovery in the event that something goes wrong

See the release notes for the complete list of changes.

Read More

Announcing Django Evolution 2.0

After 3 years of development, and a pretty massive rewrite, we’ve released Django Evolution 2.0.

Django Evolution is an add-on for Django that helps developer make and maintain changes to the schema of the database.

This is similar to (and predates) Django’s own migrations support, but allows for faster database upgrades and supports older versions of Django. It’s better suited for the needs of self-installable web applications (such as Review Board) that may go years between upgrades and need to minimize the amount of downtime.

This new major release of Django Evolution introduces:

  • Support for Python 2.7 and 3.5 through 3.8
  • Support Django 1.6 through 3.1
  • Full management of both evolutions and Django’s migrations, using the evolve command
  • Superior compatibility with a range of versions of SQLite, MySQL, MariaDB, and Postgres
  • Full API for fine-tune control of evolutions (useful for apps with extensions, or installers that manage an app’s database)

There’s also all-new documentation, and a full breakdown of the changes in the release notes.

Read More