A Sneak Peak Into the New RBCommons

Our team’s been hard at work bringing RBCommons to the cutting-edge Review Board 7 platform. This is a massive update with tons of new features, and we think it’s time to give you a glimpse of what’s coming:

Multi-commit review requests for Git and Mercurial

In the past decade, DVCS has become the norm, and many people work in local branches with lots of individual commits. Previously, any code changes posted to RBCommons would show up as a squashed diff, merely showing the difference between the upstream code and the tip of the local branch.

When using DVCS systems like Git or Mercurial, RBTools will now upload the commit history of your branch. You can look at the diff of the branch as a whole, but also dig down into each individual commit.

A list of commits for a review request, with summaries for each and selectors for choosing a range to view.

An improved review experience

Until now, your draft review requests, reviews, and replies were all managed separately, each with their own green draft banner. While it was obvious when there was a draft review request update or a draft review, sometimes draft replies could get lost in long threads.

The new unified banner always sits at the top of the page, and collects all your work together in one place. You can also use this to publish all your drafts at once with a single click and a single-email notification.

The new review banner, showing pending changes, one review, and one reply. A button saying "Publish All" to the right of that summary publishes all pending drafts. A "Review" drop-down to the right of the button controls the review. A "Describe your changes" field sits below it.

Dark mode

There’s nothing worse than staying up late to review code and feeling blinded by your screen. With dark mode, you can reduce eye strain and work comfortably no matter the time of day.

A typical review request, but shown in dark mode, with a dark cool-blue color palette.

And just so much more

There’s a lot more coming, but we wanted to keep this first message short. We’re working hard to make this transition as seamless as possible for you. Keep an eye out for more details about all the new features and a timeline for the rollout.

If you have any questions, please feel free to reply to this e-mail.

Thanks for using RBCommons! We’re excited to bring Review Board 7 to you.

Read More

beanbag-docutils 2.2: Enhanced JSON Output

beanbag-docutils is our collection of extensions for the Sphinx documentation platform.

This is a major feature release that introduces some new capabilities for JSON output, making it easier to integrate documentation into your own sites:

  • The metadata extension extracts .. meta:: into the JSON output for a page.
  • The json_writer extension replaces the sphinxcontrib-serializinghtml JSON writer and includes both a copy of the docs-wide Table of Contents structure in the globalcontext.fjson file and per-page anchor navigation HTML in the page’s .fjson file.

You can see how we make use of these new capabilities in the brand-new Review Board documentation site.

Installation

$ pip3 install beanbag-docutils==2.2

Learn More

Read More

Djblets 3.1: Token Deprecations and API Fixes

We’ve released Djblets 3.1, our collection of production-quality add-ons for Django.

This release features:

  • Ability to deprecate token generators
  • Deprecated token information in the API
  • Fixes for URI template name collisions in the API
  • Fixes for generating the new API tokens introduced in Djblets 3
  • Python 3 type hints for the djblets.registries, djblets.secrets, and djblets.siteconfig models

For complete details, see the release notes.

Read More

Django Evolution 2.2: Django 3.2-4.1 Support

Django Evolution 2.2 is a major feature release, offering new database features, improved compatibility, and several bug fixes.

Django Evolution is our alternative database migration library for Django, which supports a wide range of Django versions and optimized application of database changes. It targets self-managed applications, like Review Board, which may potentially go several releases between upgrades.

The highlights include:

  • Compatibility with Django 1.6 through 4.1, and Python 2.7 through 3.11
  • Support for conditions, expressions, opclasses, and field lists in Django’s Index classes.
  • Ability to change field types in ChangeField.
  • Improved settings for defining project-provided custom evolutions.
  • Bug fixes for MySQL compatibility, edge cases in SQL generation for indexes, and Python 3.10 compatibility.

The release notes cover the full list of changes in Django Evolution 2.2.

Read More

RBTools 3.1.2, Power Pack 5.1.1

Today, we’re bringing two new releases of RBTools and Power Pack, focusing on stability and feature improvements.

RBTools 3.1.2 Highlights

  • Now supports the upcoming Python 3.11.
  • Added back directory change information to diffs for ClearCase and VersionVault, and fixed problems posting symlinks.
  • Fixed several issues generating Perforce diffs, especially on Python 3.
  • Fixed applied patches on Subversion.

To learn more about this release, see the RBTools 3.1.2 release notes.

Power Pack 5.1.1 Highlights

  • Added support for showing changes to directories when using ClearCase or VersionVault
  • Fixed broken repository configuration forms when selecting Cliosoft SOS on Review Board 4.0.3 or older.

This upgrade is available for all existing Power Pack users.

To learn more about this release, see the Power Pack 5.1.1 release notes.

Read More

Djblets 2.3: Preparing for the Future

Djblets 2.3 is now out. This release adds compatibility fixes for Python 3.10 and gets our code ready to move to newer dependencies.

Highlights include:

  • Python 3.10 compatibility shims for Django 1.11.
  • Modern Django middleware support for extensions.
  • Babel 7.x for building extension static media files.
  • Full compatibility with Python-Markdown 2.x.
  • Support for caching data in cache_memoize() without needing to wrap in a list or string.

We’re getting 3.x ready for release. This will move the codebase to require Python 3.7+ and Django 3.2 LTS, finally bringing support for modern codebases.

See the release notes for the full list of changes.

Read More

Django Evolution 2.1.3: Evolution and compatibility fixes

Django Evolution 2.1.3 a small but important bug fix release that addresses issues with Python 3.10, mysqlclient, and evolving very old databases.

Compatibility Fixes

Python 3.10 removed some deprecated imports from collections, which Django 2.0 and older depend on. When using this combination of versions, Django Evolution will bring back those legacy imports, allowing Django to work again.

mysqlclient also received a similar fix. Django 1.11 and older depended on some unintentional functionality, which mysqlclient maintained until the 2.1 release. We now patch these versions of Django at runtime to continue working.

Upgrade Fixes

Two important issues affecting upgrades were addressed:

  1. Django Evolution no longer tries to apply evolutions to models that were just introduced. This was a regression from previous releases.
  2. When upgrading from very old databases, some state for a model’s unique_together index couldn’t be compared properly, causing issues applying some upgrades. The old format for this state is now taken into account during comparison.

Coming Up…

We’re preparing Django Evolution 2.2, which will support all versions of Django up through 4.0. This should be coming soon.

In the meantime, check out the release notes for the full changes, including other fixes in this release.

Read More

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