@@ -222,3 +222,96 @@ This is best avoided by updating to non-legacy usage:
222
222
223
223
# or, equivalently...
224
224
$ tox r -e list
225
+
226
+ Packaging environments
227
+ ----------------------
228
+
229
+ Isolated environment on by default
230
+ ++++++++++++++++++++++++++++++++++
231
+ ``tox `` now always uses an isolated build environment when building your projects package. The previous flag to enable
232
+ this called ``isolated_build `` has been removed.
233
+
234
+ Packaging configuration and inheritance
235
+ +++++++++++++++++++++++++++++++++++++++
236
+ Isolated build environments are tox environments themselves and may be configured on their own. Their name is defined
237
+ as follows:
238
+
239
+ - For source distributions this environment will match a virtual environment with the same python interpreter as tox is
240
+ using. The name of this environment will by default ``.pkg `` (can be changed via :ref: `package_env ` config on a per
241
+ test environment basis).
242
+ - For wheels (including editable wheels as defined by :pep: `660 `) their name will be ``.pkg-<impl><python_version> ``, so
243
+ for example if you're building a wheel for a Python 3.10 environment the packaging environment will be
244
+ ``.pkg-cpython311 `` (can be changed via :ref: `wheel_build_env ` config on a per test environment basis).
245
+
246
+ To change a packaging environments settings you can use:
247
+
248
+ .. code-block :: ini
249
+
250
+ [testenv:.pkg]
251
+ pass_env =
252
+ PKG_CONFIG
253
+ PKG_CONFIG_PATH
254
+ PKG_CONFIG_SYSROOT_DIR
255
+
256
+ [testenv:.pkg-cpython311]
257
+ pass_env =
258
+ PKG_CONFIG
259
+ PKG_CONFIG_PATH
260
+ PKG_CONFIG_SYSROOT_DIR
261
+
262
+ Packaging environments no longer inherit their settings from the ``testenv `` section, as this caused issues when
263
+ some test environment settings conflicted with packaging setting. However starting with ``tox>=4.2 `` all packaging
264
+ environments inherit from the ``pkgenv `` section, allowing you to define packaging common packaging settings in one
265
+ central place, while still allowing you to override it when needed on a per package environment basis:
266
+
267
+ .. code-block :: ini
268
+
269
+ [pkgenv]
270
+ pass_env =
271
+ PKG_CONFIG
272
+ PKG_CONFIG_PATH
273
+ PKG_CONFIG_SYSROOT_DIR
274
+
275
+ [testenv:.pkg-cpython311]
276
+ pass_env =
277
+ {[pkgenv]pass_env}
278
+ IS_311 = yes
279
+
280
+ [testenv:magic]
281
+ package = sdist
282
+ pass_env = {[pkgenv]pass_env} # sdist install builds wheel -> need packaging settings
283
+
284
+ Note that specific packaging environments are defined under ``testenv:.pkg `` and **not ** ``pkgenv:.pkg ``, this is due
285
+ backwards compatibility.
286
+
287
+ Universal wheels
288
+ ++++++++++++++++
289
+ If your project builds universal wheels you can avoid using multiple build environments for each targeted python by
290
+ setting :ref: `wheel_build_env ` to the same packaging environment via:
291
+
292
+ .. code-block :: ini
293
+
294
+ [testenv]
295
+ package = wheel
296
+ wheel_build_env = .pkg
297
+
298
+ Editable mode
299
+ +++++++++++++
300
+ ``tox `` now defaults to using editable wheels when develop mode is enabled and the build backend supports it,
301
+ as defined by :pep: `660 ` by setting :ref: `package ` to ``editable ``. In case the backend does not support it, will
302
+ fallback to :ref: `package ` to ``editable-legacy ``, and invoke pip with ``-e ``. In the later case will also print a
303
+ message to make this setting explicit in your configuration (explicit better than implicit):
304
+
305
+ .. code-block :: ini
306
+
307
+ [testenv:dev]
308
+ package = editable-legacy
309
+
310
+ If you want to use the new standardized method to achieve the editable install effect you should ensure your backend
311
+ version is above the version this feature was added to it, for example for setuptools:
312
+
313
+ .. code-block :: ini
314
+
315
+ [testenv:dev]
316
+ deps = setuptools>=64
317
+ package = editable
0 commit comments