|
8 | 8 | msgstr "" |
9 | 9 | "Project-Id-Version: Python Packaging User Guide \n" |
10 | 10 | "Report-Msgid-Bugs-To: \n" |
11 | | -"POT-Creation-Date: 2024-09-24 16:09+0000\n" |
| 11 | +"POT-Creation-Date: 2024-10-15 11:23+0000\n" |
12 | 12 | "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" |
13 | 13 | "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" |
14 | 14 | "Language-Team: LANGUAGE < [email protected]>\n" |
@@ -1218,78 +1218,74 @@ msgid "Complete" |
1218 | 1218 | msgstr "" |
1219 | 1219 |
|
1220 | 1220 | #: ../source/discussions/single-source-version.rst:8 |
1221 | | -msgid "2024-08-24" |
| 1221 | +msgid "2024-10-07" |
1222 | 1222 | msgstr "" |
1223 | 1223 |
|
1224 | 1224 | #: ../source/discussions/single-source-version.rst:10 |
1225 | | -msgid "One of the challenges in building packages is that the version string can be required in multiple places." |
| 1225 | +msgid "Many Python :term:`distribution packages <Distribution Package>` publish a single Python :term:`import package <Import Package>` where it is desired that the runtime ``__version__`` attribute on the import package report the same version specifier as :func:`importlib.metadata.version` reports for the distribution package (as described in :ref:`runtime-version-access`)." |
1226 | 1226 | msgstr "" |
1227 | 1227 |
|
1228 | | -#: ../source/discussions/single-source-version.rst:13 |
1229 | | -msgid "It needs to be specified when building the package (e.g. in :file:`pyproject.toml`)" |
| 1228 | +#: ../source/discussions/single-source-version.rst:16 |
| 1229 | +msgid "It is also frequently desired that this version information be derived from a version control system *tag* (such as ``v1.2.3``) rather than being manually updated in the source code." |
1230 | 1230 | msgstr "" |
1231 | 1231 |
|
1232 | | -#: ../source/discussions/single-source-version.rst:13 |
1233 | | -msgid "This will make it available in the installed package’s metadata, from where it will be accessible at runtime using ``importlib.metadata.version(\"distribution_name\")``." |
| 1232 | +#: ../source/discussions/single-source-version.rst:20 |
| 1233 | +msgid "Some projects may choose to simply live with the data entry duplication, and rely on automated testing to ensure the different values do not diverge." |
1234 | 1234 | msgstr "" |
1235 | 1235 |
|
1236 | | -#: ../source/discussions/single-source-version.rst:15 |
1237 | | -msgid "A package may set a module attribute (e.g., ``__version__``) to provide an alternative means of runtime access to the version of the imported package. If this is done, the value of the attribute and that used by the build system to set the distribution's version should be kept in sync in :ref:`the build systems's recommended way <Build system version handling>`." |
1238 | | -msgstr "" |
1239 | | - |
1240 | | -#: ../source/discussions/single-source-version.rst:17 |
1241 | | -msgid "If the code is in in a version control system (VCS), e.g. Git, the version may appear in a *tag* such as ``v1.2.3``." |
1242 | | -msgstr "" |
1243 | | - |
1244 | | -#: ../source/discussions/single-source-version.rst:19 |
1245 | | -msgid "To ensure that version numbers do not get out of sync, it is recommended that there is a single source of truth for the version number." |
| 1236 | +#: ../source/discussions/single-source-version.rst:23 |
| 1237 | +msgid "Alternatively, a project's chosen build system may offer a way to define a single source of truth for the version number." |
1246 | 1238 | msgstr "" |
1247 | 1239 |
|
1248 | | -#: ../source/discussions/single-source-version.rst:21 |
| 1240 | +#: ../source/discussions/single-source-version.rst:26 |
1249 | 1241 | msgid "In general, the options are:" |
1250 | 1242 | msgstr "" |
1251 | 1243 |
|
1252 | | -#: ../source/discussions/single-source-version.rst:23 |
1253 | | -msgid "If the code is in a version control system (VCS), e.g. Git, then the version can be extracted from the VCS." |
| 1244 | +#: ../source/discussions/single-source-version.rst:28 |
| 1245 | +msgid "If the code is in a version control system (VCS), such as Git, then the version can be extracted from the VCS." |
1254 | 1246 | msgstr "" |
1255 | 1247 |
|
1256 | | -#: ../source/discussions/single-source-version.rst:25 |
| 1248 | +#: ../source/discussions/single-source-version.rst:30 |
1257 | 1249 | msgid "The version can be hard-coded into the :file:`pyproject.toml` file -- and the build system can copy it into other locations it may be required." |
1258 | 1250 | msgstr "" |
1259 | 1251 |
|
1260 | | -#: ../source/discussions/single-source-version.rst:27 |
1261 | | -msgid "The version string can be hard-coded into the source code -- either in a special purpose file, such as :file:`_version.txt`, or as a attribute in a module, such as :file:`__init__.py`, and the build system can extract it at build time." |
| 1252 | +#: ../source/discussions/single-source-version.rst:33 |
| 1253 | +msgid "The version string can be hard-coded into the source code -- either in a special purpose file, such as :file:`_version.txt` (which must then be shipped as part of the project's source distribution package), or as an attribute in a particular module, such as :file:`__init__.py`. The build system can then extract it from the runtime location at build time." |
1262 | 1254 | msgstr "" |
1263 | 1255 |
|
1264 | | -#: ../source/discussions/single-source-version.rst:30 |
| 1256 | +#: ../source/discussions/single-source-version.rst:38 |
1265 | 1257 | msgid "Consult your build system's documentation for their recommended method." |
1266 | 1258 | msgstr "" |
1267 | 1259 |
|
1268 | | -#: ../source/discussions/single-source-version.rst:35 |
| 1260 | +#: ../source/discussions/single-source-version.rst:40 |
| 1261 | +msgid "When the intention is that a distribution package and its associated import package share the same version, it is recommended that the project include an automated test case that ensures ``import_name.__version__`` and ``importlib.metadata.version(\"dist-name\")`` report the same value (note: for many projects, ``import_name`` and ``dist-name`` will be the same name)." |
| 1262 | +msgstr "" |
| 1263 | + |
| 1264 | +#: ../source/discussions/single-source-version.rst:50 |
1269 | 1265 | msgid "Build System Version Handling" |
1270 | 1266 | msgstr "" |
1271 | 1267 |
|
1272 | | -#: ../source/discussions/single-source-version.rst:37 |
| 1268 | +#: ../source/discussions/single-source-version.rst:52 |
1273 | 1269 | msgid "The following are links to some build system's documentation for handling version strings." |
1274 | 1270 | msgstr "" |
1275 | 1271 |
|
1276 | | -#: ../source/discussions/single-source-version.rst:39 |
| 1272 | +#: ../source/discussions/single-source-version.rst:54 |
1277 | 1273 | msgid "`Flit <https://flit.pypa.io/en/stable/>`_" |
1278 | 1274 | msgstr "" |
1279 | 1275 |
|
1280 | | -#: ../source/discussions/single-source-version.rst:41 |
| 1276 | +#: ../source/discussions/single-source-version.rst:56 |
1281 | 1277 | msgid "`Hatchling <https://hatch.pypa.io/1.9/version/>`_" |
1282 | 1278 | msgstr "" |
1283 | 1279 |
|
1284 | | -#: ../source/discussions/single-source-version.rst:43 |
| 1280 | +#: ../source/discussions/single-source-version.rst:58 |
1285 | 1281 | msgid "`PDM <https://pdm-project.org/en/latest/reference/pep621/#__tabbed_1_2>`_" |
1286 | 1282 | msgstr "" |
1287 | 1283 |
|
1288 | | -#: ../source/discussions/single-source-version.rst:45 |
| 1284 | +#: ../source/discussions/single-source-version.rst:60 |
1289 | 1285 | msgid "`Setuptools <https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html#dynamic-metadata>`_" |
1290 | 1286 | msgstr "" |
1291 | 1287 |
|
1292 | | -#: ../source/discussions/single-source-version.rst:47 |
| 1288 | +#: ../source/discussions/single-source-version.rst:62 |
1293 | 1289 | msgid "`setuptools_scm <https://setuptools-scm.readthedocs.io/en/latest/>`_" |
1294 | 1290 | msgstr "" |
1295 | 1291 |
|
@@ -1507,27 +1503,59 @@ msgstr "" |
1507 | 1503 | msgid "Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a *year.serial* numbering scheme that readily conveys the approximate age of a release, but doesn't otherwise commit to a particular release cadence within the year." |
1508 | 1504 | msgstr "" |
1509 | 1505 |
|
1510 | | -#: ../source/discussions/versioning.rst:158 |
| 1506 | +#: ../source/discussions/versioning.rst:157 |
1511 | 1507 | #: ../source/specifications/version-specifiers.rst:114 |
1512 | 1508 | msgid "Local version identifiers" |
1513 | 1509 | msgstr "" |
1514 | 1510 |
|
1515 | | -#: ../source/discussions/versioning.rst:160 |
| 1511 | +#: ../source/discussions/versioning.rst:159 |
1516 | 1512 | msgid "Public version identifiers are designed to support distribution via :term:`PyPI <Python Package Index (PyPI)>`. Python packaging tools also support the notion of a :ref:`local version identifier <local-version-identifiers>`, which can be used to identify local development builds not intended for publication, or modified variants of a release maintained by a redistributor." |
1517 | 1513 | msgstr "" |
1518 | 1514 |
|
1519 | | -#: ../source/discussions/versioning.rst:166 |
| 1515 | +#: ../source/discussions/versioning.rst:165 |
1520 | 1516 | msgid "A local version identifier takes the form of a public version identifier, followed by \"+\" and a local version label. For example, a package with Fedora-specific patches applied could have the version \"1.2.1+fedora.4\". Another example is versions computed by setuptools-scm_, a setuptools plugin that reads the version from Git data. In a Git repository with some commits since the latest release, setuptools-scm generates a version like \"0.5.dev1+gd00980f\", or if the repository has untracked changes, like \"0.5.dev1+gd00980f.d20231217\"." |
1521 | 1517 | msgstr "" |
1522 | 1518 |
|
1523 | | -#: ../source/discussions/versioning.rst:178 |
| 1519 | +#: ../source/discussions/versioning.rst:177 |
| 1520 | +msgid "Accessing version information at runtime" |
| 1521 | +msgstr "" |
| 1522 | + |
| 1523 | +#: ../source/discussions/versioning.rst:179 |
| 1524 | +msgid "Version information for all :term:`distribution packages <Distribution Package>` that are locally available in the current environment can be obtained at runtime using the standard library's :func:`importlib.metadata.version` function::" |
| 1525 | +msgstr "" |
| 1526 | + |
| 1527 | +#: ../source/discussions/versioning.rst:186 |
| 1528 | +msgid "Many projects also choose to version their top level :term:`import packages <Import Package>` by providing a package level ``__version__`` attribute::" |
| 1529 | +msgstr "" |
| 1530 | + |
| 1531 | +#: ../source/discussions/versioning.rst:194 |
| 1532 | +msgid "This technique can be particularly valuable for CLI applications which want to ensure that version query invocations (such as ``pip -V``) run as quickly as possible." |
| 1533 | +msgstr "" |
| 1534 | + |
| 1535 | +#: ../source/discussions/versioning.rst:198 |
| 1536 | +msgid "Package publishers wishing to ensure their reported distribution package and import package versions are consistent with each other can review the :ref:`single-source-version` discussion for potential approaches to doing so." |
| 1537 | +msgstr "" |
| 1538 | + |
| 1539 | +#: ../source/discussions/versioning.rst:202 |
| 1540 | +msgid "As import packages and modules are not *required* to publish runtime version information in this way (see the rejected proposal in :pep:`PEP 396 <396>`), the ``__version__`` attribute should either only be queried with interfaces that are known to provide it (such as a project querying its own version or the version of one of its direct dependencies), or else the querying code should be designed to handle the case where the attribute is missing [#fallback-to-dist-version]_." |
| 1541 | +msgstr "" |
| 1542 | + |
| 1543 | +#: ../source/discussions/versioning.rst:210 |
| 1544 | +msgid "Some projects may need to publish version information for external APIs that don't meet the requirements for Python distribution package :ref:`version specifiers <version-specifiers>`. Such projects should define their own project-specific ways of obtaining the relevant information at runtime. For example, the standard library's :mod:`ssl` module offers multiple ways to access the underlying OpenSSL library version::" |
| 1545 | +msgstr "" |
| 1546 | + |
| 1547 | +#: ../source/discussions/versioning.rst:226 |
1524 | 1548 | msgid "Some more examples of unusual version numbers are given in a `blog post <versions-seth-larson_>`_ by Seth Larson." |
1525 | 1549 | msgstr "" |
1526 | 1550 |
|
1527 | | -#: ../source/discussions/versioning.rst:181 |
| 1551 | +#: ../source/discussions/versioning.rst:229 |
1528 | 1552 | msgid "For some personal viewpoints on this issue, see these blog posts: `by Hynek Schlawak <semver-hynek-schlawack_>`_, `by Donald Stufft <semver-donald-stufft_>`_, `by Bernát Gábor <semver-bernat-gabor_>`_, `by Brett Cannon <semver-brett-cannon_>`_. For a humoristic take, read about ZeroVer_." |
1529 | 1553 | msgstr "" |
1530 | 1554 |
|
| 1555 | +#: ../source/discussions/versioning.rst:235 |
| 1556 | +msgid "A full list mapping the top level names available for import to the distribution packages that provide those import packages and modules may be obtained through the standard library's :func:`importlib.metadata.packages_distributions` function. This means that even code that is attempting to infer a version to report for all importable top-level names has a means to fall back to reporting the distribution version information if no ``__version__`` attribute is defined. Only standard library modules, and modules added via means other than Python package installation would fail to have version information reported in that case." |
| 1557 | +msgstr "" |
| 1558 | + |
1531 | 1559 | #: ../source/flow.rst:3 |
1532 | 1560 | msgid "The Packaging Flow" |
1533 | 1561 | msgstr "" |
@@ -2607,7 +2635,6 @@ msgid "First of all, create a source tree for the :term:`project <Project>`. For |
2607 | 2635 | msgstr "" |
2608 | 2636 |
|
2609 | 2637 | #: ../source/guides/creating-command-line-tools.rst:17 |
2610 | | -#: ../source/guides/single-sourcing-package-version.rst:7 |
2611 | 2638 | #: ../source/guides/tool-recommendations.rst:45 |
2612 | 2639 | msgid "Todo" |
2613 | 2640 | msgstr "" |
@@ -5181,96 +5208,16 @@ msgstr "" |
5181 | 5208 | msgid "Installation" |
5182 | 5209 | msgstr "" |
5183 | 5210 |
|
5184 | | -#: ../source/guides/single-sourcing-package-version.rst:5 |
5185 | | -msgid "Single-sourcing the package version" |
5186 | | -msgstr "" |
5187 | | - |
5188 | | -#: ../source/guides/single-sourcing-package-version.rst:7 |
5189 | | -msgid "Update this page for build backends other than setuptools." |
5190 | | -msgstr "" |
5191 | | - |
5192 | | -#: ../source/guides/single-sourcing-package-version.rst:9 |
5193 | | -msgid "There are many techniques to maintain a single source of truth for the version number of your project:" |
5194 | | -msgstr "" |
5195 | | - |
5196 | | -#: ../source/guides/single-sourcing-package-version.rst:12 |
5197 | | -msgid "Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py <https://github.com/pypa/pip/blob/003c7ac/setup.py>`_)::" |
5198 | | -msgstr "" |
5199 | | - |
5200 | | -#: ../source/guides/single-sourcing-package-version.rst:39 |
5201 | | -msgid "As of the release of setuptools 46.4.0, one can accomplish the same thing by instead placing the following in the project's :file:`setup.cfg` file (replacing \"package\" with the import name of the package):" |
5202 | | -msgstr "" |
5203 | | - |
5204 | | -#: ../source/guides/single-sourcing-package-version.rst:49 |
5205 | | -msgid "As of the release of setuptools 61.0.0, one can specify the version dynamically in the project's :file:`pyproject.toml` file." |
5206 | | -msgstr "" |
5207 | | - |
5208 | | -#: ../source/guides/single-sourcing-package-version.rst:61 |
5209 | | -msgid "Please be aware that declarative config indicators, including the ``attr:`` directive, are not supported in parameters to :file:`setup.py`." |
5210 | | -msgstr "" |
5211 | | - |
5212 | | -#: ../source/guides/single-sourcing-package-version.rst:65 |
5213 | | -msgid "Use an external build tool that either manages updating both locations, or offers an API that both locations can use." |
5214 | | -msgstr "" |
5215 | | - |
5216 | | -#: ../source/guides/single-sourcing-package-version.rst:68 |
5217 | | -msgid "Few tools you could use, in no particular order, and not necessarily complete: `bump2version <https://pypi.org/project/bump2version>`_, `changes <https://pypi.org/project/changes>`_, `commitizen <https://pypi.org/project/commitizen>`_, `zest.releaser <https://pypi.org/project/zest.releaser>`_." |
5218 | | -msgstr "" |
5219 | | - |
5220 | | -#: ../source/guides/single-sourcing-package-version.rst:75 |
5221 | | -msgid "Set the value to a ``__version__`` global variable in a dedicated module in your project (e.g. :file:`version.py`), then have :file:`setup.py` read and ``exec`` the value into a variable." |
5222 | | -msgstr "" |
5223 | | - |
5224 | | -#: ../source/guides/single-sourcing-package-version.rst:86 |
5225 | | -msgid "Example using this technique: `warehouse <https://github.com/pypa/warehouse/blob/64ca42e42d5613c8339b3ec5e1cb7765c6b23083/warehouse/__about__.py>`_." |
5226 | | -msgstr "" |
5227 | | - |
5228 | | -#: ../source/guides/single-sourcing-package-version.rst:88 |
5229 | | -msgid "Place the value in a simple ``VERSION`` text file and have both :file:`setup.py` and the project code read it." |
5230 | | -msgstr "" |
5231 | | - |
5232 | | -#: ../source/guides/single-sourcing-package-version.rst:96 |
5233 | | -msgid "An advantage with this technique is that it's not specific to Python. Any tool can read the version." |
5234 | | -msgstr "" |
5235 | | - |
5236 | | -#: ../source/guides/single-sourcing-package-version.rst:101 |
5237 | | -msgid "With this approach you must make sure that the ``VERSION`` file is included in all your source and binary distributions (e.g. add ``include VERSION`` to your :file:`MANIFEST.in`)." |
5238 | | -msgstr "" |
5239 | | - |
5240 | | -#: ../source/guides/single-sourcing-package-version.rst:105 |
5241 | | -msgid "Set the value in :file:`setup.py`, and have the project code use the ``importlib.metadata`` API to fetch the value at runtime. (``importlib.metadata`` was introduced in Python 3.8 and is available to older versions as the ``importlib-metadata`` project.) An installed project's version can be fetched with the API as follows::" |
5242 | | -msgstr "" |
5243 | | - |
5244 | | -#: ../source/guides/single-sourcing-package-version.rst:120 |
5245 | | -msgid "Be aware that the ``importlib.metadata`` API only knows about what's in the installation metadata, which is not necessarily the code that's currently imported." |
5246 | | -msgstr "" |
5247 | | - |
5248 | | -#: ../source/guides/single-sourcing-package-version.rst:124 |
5249 | | -msgid "If a project uses this method to fetch its version at runtime, then its ``install_requires`` value needs to be edited to install ``importlib-metadata`` on pre-3.8 versions of Python like so::" |
5250 | | -msgstr "" |
5251 | | - |
5252 | | -#: ../source/guides/single-sourcing-package-version.rst:138 |
5253 | | -msgid "An older (and less efficient) alternative to ``importlib.metadata`` is the ``pkg_resources`` API provided by ``setuptools``::" |
5254 | | -msgstr "" |
5255 | | - |
5256 | | -#: ../source/guides/single-sourcing-package-version.rst:144 |
5257 | | -msgid "If a project uses ``pkg_resources`` to fetch its own version at runtime, then ``setuptools`` must be added to the project's ``install_requires`` list." |
5258 | | -msgstr "" |
5259 | | - |
5260 | | -#: ../source/guides/single-sourcing-package-version.rst:148 |
5261 | | -msgid "Example using this technique: `setuptools <https://github.com/pypa/setuptools/blob/main/setuptools/version.py>`_." |
5262 | | -msgstr "" |
5263 | | - |
5264 | | -#: ../source/guides/single-sourcing-package-version.rst:151 |
5265 | | -msgid "Set the value to ``__version__`` in ``sample/__init__.py`` and import ``sample`` in :file:`setup.py`." |
| 5211 | +#: ../source/guides/single-sourcing-package-version.rst:-1 |
| 5212 | +msgid "0; url=../../discussions/single-source-version/" |
5266 | 5213 | msgstr "" |
5267 | 5214 |
|
5268 | | -#: ../source/guides/single-sourcing-package-version.rst:165 |
5269 | | -msgid "Although this technique is common, beware that it will fail if ``sample/__init__.py`` imports packages from ``install_requires`` dependencies, which will very likely not be installed yet when :file:`setup.py` is run." |
| 5215 | +#: ../source/guides/single-sourcing-package-version.rst:6 |
| 5216 | +msgid "Redirecting stale single-source package version link..." |
5270 | 5217 | msgstr "" |
5271 | 5218 |
|
5272 | | -#: ../source/guides/single-sourcing-package-version.rst:171 |
5273 | | -msgid "Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using `setuptools_scm <https://pypi.org/project/setuptools-scm/>`_." |
| 5219 | +#: ../source/guides/single-sourcing-package-version.rst:8 |
| 5220 | +msgid "If the page doesn't automatically refresh, see :ref:`single-source-version`." |
5274 | 5221 | msgstr "" |
5275 | 5222 |
|
5276 | 5223 | #: ../source/guides/supporting-multiple-python-versions.rst:7 |
@@ -5920,7 +5867,7 @@ msgid "This field is required, although it is often marked as dynamic using" |
5920 | 5867 | msgstr "" |
5921 | 5868 |
|
5922 | 5869 | #: ../source/guides/writing-pyproject-toml.rst:165 |
5923 | | -msgid "This allows use cases such as filling the version from a ``__version__`` attribute or a Git tag. Consult :ref:`Single sourcing the version` for more details." |
| 5870 | +msgid "This allows use cases such as filling the version from a ``__version__`` attribute or a Git tag. Consult the :ref:`single-source-version` discussion for more details." |
5924 | 5871 | msgstr "" |
5925 | 5872 |
|
5926 | 5873 | #: ../source/guides/writing-pyproject-toml.rst:171 |
|
0 commit comments