Summary

Add the buildthings build backend.

Review Request #14951 — Created March 20, 2026 and submitted March 27, 2026, 8 a.m.

Information

Owner

chipx86

Repository

buildthings

Branch

master

Bugs

Depends On

Reviewers

Groups

beanbag-misc

People

Description

It's based on the build backends we introduced in Review Board and
Djblets, but more refined and capable of being expanded for additional
use cases down the road.

This initial version supports:

.local-packages/, mapping dependency names to local source trees,
used in isolated build environments (available per-build type).
Options for including dev- and install-time dependencies within the
isolated build environments (available per-build type).
An option for excluding certain, more complex dependencies from the
isolated environments (available per-build type).
Options for enabling NPM installs and for managing workspaces based on
other Python packages.
Support for extra build steps for editables, wheels, and source
distributions.

Much of this behaves the way it did in our in-tree build backends, but
with several behavior issues fixed. For example, development
dependencies will now map to local paths if found in .local-packages/.
Further, depending on an editable package using this backend will no
longer error out when it in turn depends on other local trees.

Full documentation for all the options are available in the README.

Testing Done

Converted Djblets and Review Board over to buildthings.

Tested building in new virtualenvs using editable mode, ensuring
that .local-packages was picked up, and using the install deps
options.

Checked that when building Review Board, the Djblets .local-packages
was used.

Verified that the local packages weren't installed as package
dependencies (which would override any editable installs).

Tested various combinations of the options and overrides.

Tested building sdist and wheel distributions, with and without
.local-packages and other deps turned on.

Tested the build steps support.

Tested that when building packages with include-{dev,install}-deps,
those packages were installed in the environment but that the
development deps didn't become part of the final package's dependency
list.

Commits

Summary	ID
Add the buildthings build backend. Buildthings is a setuptools-based Python build backend that makes it easier to work with projects with more complex build requirements, particularly those involving NPM or packages that may still be in development in local source trees. It's based on the build backends we introduced in Review Board and Djblets, but more refined and capable of being expanded for additional use cases down the road. This initial version supports: * `.local-packages/`, mapping dependency names to local source trees, used in isolated build environments (available per-build type). * Options for including dev- and install-time dependencies within the isolated build environments (available per-build type). * An option for excluding certain, more complex dependencies from the isolated environments (available per-build type). * Options for enabling NPM installs and for managing workspaces based on other Python packages. * Support for extra build steps for editables, wheels, and source distributions. Much of this behaves the way it did in our in-tree build backends, but with several behavior issues fixed. For example, development dependencies will now map to local paths if found in `.local-packages/`. Further, depending on an editable package using this backend will no longer error out when it in turn depends on other local trees. Full documentation for all the options are available in the README.	507d56edb28f26676642250128dd531a02ad1abb

Summary

Add the buildthings build backend.

Buildthings is a setuptools-based Python build backend that makes it easier to work with projects with more complex build requirements, particularly those involving NPM or packages that may still be in development in local source trees. It's based on the build backends we introduced in Review Board and Djblets, but more refined and capable of being expanded for additional use cases down the road. This initial version supports: * `.local-packages/`, mapping dependency names to local source trees, used in isolated build environments (available per-build type). * Options for including dev- and install-time dependencies within the isolated build environments (available per-build type). * An option for excluding certain, more complex dependencies from the isolated environments (available per-build type). * Options for enabling NPM installs and for managing workspaces based on other Python packages. * Support for extra build steps for editables, wheels, and source distributions. Much of this behaves the way it did in our in-tree build backends, but with several behavior issues fixed. For example, development dependencies will now map to local paths if found in `.local-packages/`. Further, depending on an editable package using this backend will no longer error out when it in turn depends on other local trees. Full documentation for all the options are available in the README.

507d56edb28f26676642250128dd531a02ad1abb

Issues

Description	From	Last Updated
We need to add toml as a dependency for python_version<3.11	david	March 24, 2026, 3:42 a.m.
There's no override of prepare_metadata_for_build_sdist. Should we have one?	david	March 24, 2026, 3:44 a.m.
This should probably have a line of ===== above it too.	david	March 24, 2026, 3:44 a.m.
'from setuptools.build_meta import *' used; unable to detect undefined names Column: 1 Error code: F403	reviewbot	March 20, 2026, 11:08 p.m.
'setuptools.build_meta.*' imported but unused Column: 1 Error code: F401	reviewbot	March 20, 2026, 11:08 p.m.
Looks like some of this might have been copy/pasted from sdist	david	March 24, 2026, 3:45 a.m.
Are these things actually necessary for the metadata operation? This is pretty heavyweight, and seems like it could be limited …	david	March 24, 2026, 5:20 a.m.
The local_packages_path in isolation_config is str \| None but apply_local_dep_paths types this as str	david	March 24, 2026, 3:46 a.m.
This will end up computing npm_workspaces_dir relative to buildthings/backend.py. I think we want the cwd instead.	david	March 24, 2026, 3:47 a.m.
Because command is an str, this needs shell=True	david	March 24, 2026, 3:47 a.m.
We should pass text=True to subprocess.run(), otherwise the error will look like this: Failed to install npm packages: b'...'	david	March 24, 2026, 3:48 a.m.
Shouldn't this be ImportError?	david	March 24, 2026, 3:48 a.m.
This cache works when we're doing a single type of build, but in the case where a package has different …	david	March 24, 2026, 5:13 a.m.
This drops invalid requirements lines silently.	david	March 24, 2026, 5:19 a.m.
This should be able to just be < instead of <=	david	March 24, 2026, 6:40 a.m.
'from setuptools.build_meta import *' used; unable to detect undefined names Column: 1 Error code: F403	reviewbot	March 24, 2026, 5:24 a.m.
'setuptools.build_meta.*' imported but unused Column: 1 Error code: F401	reviewbot	March 24, 2026, 5:24 a.m.
Was this supposed to be included here alongside the build types?	maubin	March 24, 2026, 8:30 p.m.
This is meant to be tool.buildthings.editable.extra-build-steps	maubin	March 24, 2026, 8:31 p.m.
Typo "doen't".	maubin	March 24, 2026, 8:31 p.m.
This should just be [tool.buildthings.isolation].	maubin	March 24, 2026, 8:31 p.m.
Same here, we can remove the word "editable" since this function is used with any build type.	maubin	March 24, 2026, 8:33 p.m.
This is missing in the Args section of the docstring.	maubin	March 24, 2026, 8:33 p.m.
Do we wanna use logger here instead of a print?	maubin	March 24, 2026, 8:34 p.m.
This needs a Raises section in the docs.	maubin	March 24, 2026, 8:35 p.m.
This needs a Raises docs section too.	maubin	March 24, 2026, 8:35 p.m.
This needs a Raises docs section too.	maubin	March 24, 2026, 8:36 p.m.
exclude_deps contains package names, but deps has full dependency specifiers. We probably need to parse the items in deps and …	david	March 27, 2026, 7:56 a.m.
This shouldn't talk about Djblets and Review Board.	david	March 25, 2026, 12:54 a.m.
For now this is okay, but keying off only the leaf node might bite us in the future. Is there …	david	March 25, 2026, 12:55 a.m.
Can we document in here the stuff about different build types having different local packages, but that's okay because the …	david	March 25, 2026, 12:58 a.m.
This will quietly swallow requirements lines like -r some-other-file.txt, -e ., or --index-url .... We probably want to document that …	david	March 25, 2026, 1 a.m.

flake8 failed.

JSHint passed.

flake8

buildthings/backend.py (Diff revision 1)

The issue has been dropped. Show all issues

'from setuptools.build_meta import *' used; unable to detect undefined names

Column: 1
Error code: F403

buildthings/backend.py (Diff revision 1)

The issue has been dropped. Show all issues

'setuptools.build_meta.*' imported but unused

Column: 1
Error code: F401

Testing Done:: +
Converted Djblets and Review Board over to buildthings.
+
+
Tested building in new virtualenvs using editable mode, ensuring
+ that .local-packages was picked up, and using the install deps
+ options.
+
+
Checked that when building Review Board, the Djblets .local-packages
+ was used.
+
+
Verified that the local packages weren't installed as package
+ dependencies (which would override any editable installs).
+
+
Tested various combinations of the options and overrides.
+
+
Tested building sdist and wheel distributions, with and without
+ .local-packages and other deps turned on.
+
+
Tested the build steps support.

Testing Done:: Converted Djblets and Review Board over to buildthings.

Tested building in new virtualenvs using editable mode, ensuring
that .local-packages was picked up, and using the install deps
options.

Checked that when building Review Board, the Djblets .local-packages
was used.

Verified that the local packages weren't installed as package
dependencies (which would override any editable installs).

Tested various combinations of the options and overrides.

Tested building sdist and wheel distributions, with and without
.local-packages and other deps turned on.

Tested the build steps support.
+
+
Tested that when building packages with include-{dev,install}-deps,
+ those packages were installed in the environment but that the
+ development deps didn't become part of the final package's dependency
+ list.

The issue has been resolved. Show all issues

We need to add toml as a dependency for python_version<3.11

The issue has been dropped. Show all issues

There's no override of prepare_metadata_for_build_sdist. Should we have one?

chipx86 March 24, 2026, 5:24 a.m.

That's not one of the build backend hooks. Metadata's only for wheels, as it goes into the .dist-info directory.

README.rst (Diff revision 1)
The issue has been resolved. Show all issues
```
This should probably have a line of ===== above it too.
```

buildthings/backend.py (Diff revision 1)

The issue has been resolved. Show all issues

Looks like some of this might have been copy/pasted from sdist

buildthings/backend.py (Diff revision 1)

The issue has been resolved. Show all issues

Are these things actually necessary for the metadata operation? This is pretty heavyweight, and seems like it could be limited to run only in the actual build_* hooks.

buildthings/backend.py (Diff revision 1)

The issue has been resolved. Show all issues

The local_packages_path in isolation_config is str | None but apply_local_dep_paths types this as str

buildthings/backend.py (Diff revision 1)

The issue has been resolved. Show all issues

This will end up computing npm_workspaces_dir relative to buildthings/backend.py. I think we want the cwd instead.

buildthings/backend.py (Diff revision 1)
The issue has been resolved. Show all issues
```
Because command is an str, this needs shell=True
```

buildthings/backend.py (Diff revision 1)

The issue has been resolved. Show all issues

We should pass text=True to subprocess.run(), otherwise the error will look like this:

Failed to install npm packages: b'...'

buildthings/config.py (Diff revision 1)
The issue has been resolved. Show all issues
```
Shouldn't this be ImportError?
```

buildthings/local_paths.py (Diff revision 1)

The issue has been dropped. Show all issues

This cache works when we're doing a single type of build, but in the case where a package has different local_packages for different targets, we could mess up (for example, python -m build does both wheel and sdist by default, I believe without reloading the build backend). I think we need to have this key off the build type as well.

chipx86 March 24, 2026, 5:24 a.m.

We discussed this a bit elsewhere, but basically, PEP 517 states states that the build environment should run each hook in a fresh subprocess in order to allow the build backend to set environment variables and manage other global state without risk of conflict between hooks and build types.

This is codified in pyproject_hooks, which is the de facto way of interfacing with build backends.

I can verify that this is the case, as each hook is run with its own PID and command line arguments.

It's possible there are bad implementations out there, but not ones we will be using or recommending.

buildthings/requirements.py (Diff revision 1)
The issue has been resolved. Show all issues
```
This drops invalid requirements lines silently.
```

Change Summary:


Added toml as a dependency for Python < 3.11.
Added logging when encountering an invalid requirement line in a requirements.txt-type file.
Removed npm management during prepare_metadata_for_build_wheel().
Passed shell=True when running build steps.
Passed text=True when running npm install, to help with error reporting.
Fixed some doc issues.
Fixed apply_local_dep_paths to take a None local_packages_path.
Fixed the npm_workspaces_dir to be based on the current working directory of the tree.
Fixed an IOError that should have been ImportError.

Commits:

	Summary	ID
	Add the buildthings build backend. Buildthings is a setuptools-based Python build backend that makes it easier to work with projects with more complex build requirements, particularly those involving NPM or packages that may still be in development in local source trees. It's based on the build backends we introduced in Review Board and Djblets, but more refined and capable of being expanded for additional use cases down the road. This initial version supports: * `.local-packages/`, mapping dependency names to local source trees, used in isolated build environments (available per-build type). * Options for including dev- and install-time dependencies within the isolated build environments (available per-build type). * An option for excluding certain, more complex dependencies from the isolated environments (available per-build type). * Options for enabling NPM installs and for managing workspaces based on other Python packages. * Support for extra build steps for editables, wheels, and source distributions. Much of this behaves the way it did in our in-tree build backends, but with several behavior issues fixed. For example, development dependencies will now map to local paths if found in `.local-packages/`. Further, depending on an editable package using this backend will no longer error out when it in turn depends on other local trees. Full documentation for all the options are available in the README.	4027a0f9a480988426a486cea07259604217ef5d
	Add the buildthings build backend. Buildthings is a setuptools-based Python build backend that makes it easier to work with projects with more complex build requirements, particularly those involving NPM or packages that may still be in development in local source trees. It's based on the build backends we introduced in Review Board and Djblets, but more refined and capable of being expanded for additional use cases down the road. This initial version supports: * `.local-packages/`, mapping dependency names to local source trees, used in isolated build environments (available per-build type). * Options for including dev- and install-time dependencies within the isolated build environments (available per-build type). * An option for excluding certain, more complex dependencies from the isolated environments (available per-build type). * Options for enabling NPM installs and for managing workspaces based on other Python packages. * Support for extra build steps for editables, wheels, and source distributions. Much of this behaves the way it did in our in-tree build backends, but with several behavior issues fixed. For example, development dependencies will now map to local paths if found in `.local-packages/`. Further, depending on an editable package using this backend will no longer error out when it in turn depends on other local trees. Full documentation for all the options are available in the README.	316b1b344bd10a11858b4c6e91671dabb102d409

Diff:

Revision 2 (+4132)

Show changes

	README.rst
	pyproject.toml
	buildthings/__init__.py
	buildthings/backend.py
	buildthings/config.py
	buildthings/local_paths.py
	buildthings/requirements.py

Checks run (1 failed, 1 succeeded)

flake8 failed.

JSHint passed.

flake8

buildthings/backend.py (Diff revision 2)

The issue has been dropped. Show all issues

'from setuptools.build_meta import *' used; unable to detect undefined names

Column: 1
Error code: F403

david March 24, 2026, 5:39 a.m.

I think if you change this to be # noqa it'll do what you want.
Or we could explicitly import everything we want and reexport in __all__

buildthings/backend.py (Diff revision 2)

The issue has been dropped. Show all issues

'setuptools.build_meta.*' imported but unused

Column: 1
Error code: F401

buildthings/requirements.py (Diff revisions 1 - 2)

Oh oh oh! TIL:

return [
    parsed
    for line in fp
    if (parsed := _parse_requirement_line(line, path))
]

chipx86 March 24, 2026, 6:42 a.m.
```
Very nice.
```

pyproject.toml (Diff revisions 1 - 2)
The issue has been resolved. Show all issues
```
This should be able to just be < instead of <=
```

Change Summary:


Simplified requirement parsing code.
tool.buildthings.dependencies can now only be dynamic if specified explicitly in tool.buildthings.dynamic. This allows for static dependencies here.
Fixed the Python version range for the toml dependency.
Fixed up pyproject.toml for buildthings to work with the latest changes.

Commits:

	Summary	ID
	Add the buildthings build backend. Buildthings is a setuptools-based Python build backend that makes it easier to work with projects with more complex build requirements, particularly those involving NPM or packages that may still be in development in local source trees. It's based on the build backends we introduced in Review Board and Djblets, but more refined and capable of being expanded for additional use cases down the road. This initial version supports: * `.local-packages/`, mapping dependency names to local source trees, used in isolated build environments (available per-build type). * Options for including dev- and install-time dependencies within the isolated build environments (available per-build type). * An option for excluding certain, more complex dependencies from the isolated environments (available per-build type). * Options for enabling NPM installs and for managing workspaces based on other Python packages. * Support for extra build steps for editables, wheels, and source distributions. Much of this behaves the way it did in our in-tree build backends, but with several behavior issues fixed. For example, development dependencies will now map to local paths if found in `.local-packages/`. Further, depending on an editable package using this backend will no longer error out when it in turn depends on other local trees. Full documentation for all the options are available in the README.	316b1b344bd10a11858b4c6e91671dabb102d409
	Add the buildthings build backend. Buildthings is a setuptools-based Python build backend that makes it easier to work with projects with more complex build requirements, particularly those involving NPM or packages that may still be in development in local source trees. It's based on the build backends we introduced in Review Board and Djblets, but more refined and capable of being expanded for additional use cases down the road. This initial version supports: * `.local-packages/`, mapping dependency names to local source trees, used in isolated build environments (available per-build type). * Options for including dev- and install-time dependencies within the isolated build environments (available per-build type). * An option for excluding certain, more complex dependencies from the isolated environments (available per-build type). * Options for enabling NPM installs and for managing workspaces based on other Python packages. * Support for extra build steps for editables, wheels, and source distributions. Much of this behaves the way it did in our in-tree build backends, but with several behavior issues fixed. For example, development dependencies will now map to local paths if found in `.local-packages/`. Further, depending on an editable package using this backend will no longer error out when it in turn depends on other local trees. Full documentation for all the options are available in the README.	55006baa013819908c4b98a8293931379764a95d

Diff:

Revision 3 (+4118)

Show changes

	README.rst
	pyproject.toml
	buildthings/__init__.py
	buildthings/backend.py
	buildthings/config.py
	buildthings/local_paths.py
	buildthings/requirements.py

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

README.rst (Diff revision 3)

The issue has been resolved. Show all issues

Was this supposed to be included here alongside the build types?

README.rst (Diff revision 3)

The issue has been resolved. Show all issues

This is meant to be tool.buildthings.editable.extra-build-steps

buildthings/backend.py (Diff revision 3)
The issue has been resolved. Show all issues
```
Typo "doen't".
```
buildthings/backend.py (Diff revision 3)
The issue has been resolved. Show all issues
```
This should just be [tool.buildthings.isolation].
```

buildthings/backend.py (Diff revision 3)

The issue has been resolved. Show all issues

Same here, we can remove the word "editable" since this function is used with any build type.

buildthings/backend.py (Diff revision 3)
The issue has been resolved. Show all issues
```
This is missing in the Args section of the docstring.
```

buildthings/backend.py (Diff revision 3)

The issue has been resolved. Show all issues

Do we wanna use logger here instead of a print?

chipx86 March 24, 2026, 8:37 p.m.

This is a good question. There doesn't appear to be a standard approach. I'm seeing setuptools using both. I think a log functino is fine, though, so I'll switch to that.

buildthings/config.py (Diff revision 3)
The issue has been resolved. Show all issues
```
This needs a Raises section in the docs.
```
buildthings/config.py (Diff revision 3)
The issue has been resolved. Show all issues
```
This needs a Raises docs section too.
```
buildthings/config.py (Diff revision 3)
The issue has been resolved. Show all issues
```
This needs a Raises docs section too.
```

Change Summary:


Fixed up several issues with docs, including missing arguments and exceptions, typos, and other issues.
Switched to logger for print output.
Added toml as a build-time requirement for this package, using the proper Python version range.

Commits:

	Summary	ID
	Add the buildthings build backend. Buildthings is a setuptools-based Python build backend that makes it easier to work with projects with more complex build requirements, particularly those involving NPM or packages that may still be in development in local source trees. It's based on the build backends we introduced in Review Board and Djblets, but more refined and capable of being expanded for additional use cases down the road. This initial version supports: * `.local-packages/`, mapping dependency names to local source trees, used in isolated build environments (available per-build type). * Options for including dev- and install-time dependencies within the isolated build environments (available per-build type). * An option for excluding certain, more complex dependencies from the isolated environments (available per-build type). * Options for enabling NPM installs and for managing workspaces based on other Python packages. * Support for extra build steps for editables, wheels, and source distributions. Much of this behaves the way it did in our in-tree build backends, but with several behavior issues fixed. For example, development dependencies will now map to local paths if found in `.local-packages/`. Further, depending on an editable package using this backend will no longer error out when it in turn depends on other local trees. Full documentation for all the options are available in the README.	55006baa013819908c4b98a8293931379764a95d
	Add the buildthings build backend. Buildthings is a setuptools-based Python build backend that makes it easier to work with projects with more complex build requirements, particularly those involving NPM or packages that may still be in development in local source trees. It's based on the build backends we introduced in Review Board and Djblets, but more refined and capable of being expanded for additional use cases down the road. This initial version supports: * `.local-packages/`, mapping dependency names to local source trees, used in isolated build environments (available per-build type). * Options for including dev- and install-time dependencies within the isolated build environments (available per-build type). * An option for excluding certain, more complex dependencies from the isolated environments (available per-build type). * Options for enabling NPM installs and for managing workspaces based on other Python packages. * Support for extra build steps for editables, wheels, and source distributions. Much of this behaves the way it did in our in-tree build backends, but with several behavior issues fixed. For example, development dependencies will now map to local paths if found in `.local-packages/`. Further, depending on an editable package using this backend will no longer error out when it in turn depends on other local trees. Full documentation for all the options are available in the README.	8e0955df7c99f82b349b3f87595a60e0a438d591

Diff:

Revision 4 (+4170)

Show changes

	README.rst
	pyproject.toml
	buildthings/__init__.py
	buildthings/backend.py
	buildthings/config.py
	buildthings/local_paths.py
	buildthings/requirements.py

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

buildthings/backend.py (Diff revision 4)

The issue has been resolved. Show all issues

exclude_deps contains package names, but deps has full dependency specifiers. We probably need to parse the items in deps and canonicalize both deps and exclude_deps names before comparing them.

chipx86 March 25, 2026, 1:01 a.m.

I'm going to punt on this for right now. I'll circle back to it. This release is now a showstopper and this limitation can be worked around by specifying the full specifier.

david March 25, 2026, 1:36 a.m.
```
Can you add a TODO comment about this?
```

buildthings/backend.py (Diff revision 4)
The issue has been resolved. Show all issues
```
This shouldn't talk about Djblets and Review Board.
```

buildthings/config.py (Diff revision 4)

The issue has been dropped. Show all issues

For now this is okay, but keying off only the leaf node might bite us in the future. Is there any reason to not use the full key in self.dynamic?

chipx86 March 25, 2026, 1:01 a.m.

This is how this works in setuptools and other build backends. It's a reference to leaf keys that are handled specifically by the build backend in specific sections.

buildthings/local_paths.py (Diff revision 4)

The issue has been resolved. Show all issues

Can we document in here the stuff about different build types having different local packages, but that's okay because the build backend gets reloaded?

buildthings/requirements.py (Diff revision 4)

The issue has been resolved. Show all issues

This will quietly swallow requirements lines like -r some-other-file.txt, -e ., or --index-url .... We probably want to document that limitation in here.

chipx86 March 25, 2026, 1:01 a.m.

Same limitation that setuptools has. I'll make a note.

Change Summary:


Removed a reference to Djblets and Review Board.
Improved some docstrings.

Commits:

	Summary	ID
	Add the buildthings build backend. Buildthings is a setuptools-based Python build backend that makes it easier to work with projects with more complex build requirements, particularly those involving NPM or packages that may still be in development in local source trees. It's based on the build backends we introduced in Review Board and Djblets, but more refined and capable of being expanded for additional use cases down the road. This initial version supports: * `.local-packages/`, mapping dependency names to local source trees, used in isolated build environments (available per-build type). * Options for including dev- and install-time dependencies within the isolated build environments (available per-build type). * An option for excluding certain, more complex dependencies from the isolated environments (available per-build type). * Options for enabling NPM installs and for managing workspaces based on other Python packages. * Support for extra build steps for editables, wheels, and source distributions. Much of this behaves the way it did in our in-tree build backends, but with several behavior issues fixed. For example, development dependencies will now map to local paths if found in `.local-packages/`. Further, depending on an editable package using this backend will no longer error out when it in turn depends on other local trees. Full documentation for all the options are available in the README.	8e0955df7c99f82b349b3f87595a60e0a438d591
	Add the buildthings build backend. Buildthings is a setuptools-based Python build backend that makes it easier to work with projects with more complex build requirements, particularly those involving NPM or packages that may still be in development in local source trees. It's based on the build backends we introduced in Review Board and Djblets, but more refined and capable of being expanded for additional use cases down the road. This initial version supports: * `.local-packages/`, mapping dependency names to local source trees, used in isolated build environments (available per-build type). * Options for including dev- and install-time dependencies within the isolated build environments (available per-build type). * An option for excluding certain, more complex dependencies from the isolated environments (available per-build type). * Options for enabling NPM installs and for managing workspaces based on other Python packages. * Support for extra build steps for editables, wheels, and source distributions. Much of this behaves the way it did in our in-tree build backends, but with several behavior issues fixed. For example, development dependencies will now map to local paths if found in `.local-packages/`. Further, depending on an editable package using this backend will no longer error out when it in turn depends on other local trees. Full documentation for all the options are available in the README.	507d56edb28f26676642250128dd531a02ad1abb

Diff:

Revision 5 (+4186)

Show changes

	README.rst
	pyproject.toml
	buildthings/__init__.py
	buildthings/backend.py
	buildthings/config.py
	buildthings/local_paths.py
	buildthings/requirements.py

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Ship it!

```
Ship It!
```

Ship it!

```
Ship It!
```

Status:: Completed
Change Summary:: Pushed to master (292cc85)

	+	Converted Djblets and Review Board over to buildthings.
	+
	+	Tested building in new virtualenvs using editable mode, ensuring
	+	that `.local-packages` was picked up, and using the install deps
	+	options.
	+
	+	Checked that when building Review Board, the Djblets `.local-packages`
	+	was used.
	+
	+	Verified that the local packages weren't installed as package
	+	dependencies (which would override any editable installs).
	+
	+	Tested various combinations of the options and overrides.
	+
	+	Tested building sdist and wheel distributions, with and without
	+	`.local-packages` and other deps turned on.
	+
	+	Tested the build steps support.