TranslateProject/sources/tech/20220908 How to use modern Python packaging and setuptools plugins together.md

[#]: subject: "How to use modern Python packaging and setuptools plugins together"
[#]: via: "https://opensource.com/article/22/9/modern-python-packaging-setuptools-plugins"
[#]: author: "Moshe Zadka https://opensource.com/users/moshez"
[#]: collector: "lkxed"
[#]: translator: " "
[#]: reviewer: " "
[#]: publisher: " "
[#]: url: " "

How to use modern Python packaging and setuptools plugins together
======
Using the setuptools plugin with modern Python packaging allows for experimentation with automation.

![How to write a web service using Python Flask][1]

Image by: Yuko Honda on Flickr. CC BY-SA 2.0

Python packaging has evolved a lot. The latest ("beta") uses one file, `pyproject.toml`, to control the package.

A minimal `pyproject.toml` might look like this:

```
[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"

[project]
name = "cool_project"
version = "1.0.0"
```

### The project section

The **project** section is the data about the Python project itself, including fields like **name** and **version**, which are required.

Other fields are often used, including:

* description: A one-line description.
* readme: Location of a README file.
* authors: Author names and e-mails.
* dependencies: Other packages used by this project.

### The build-system section

Though it does not have to be first, the **build-system** usually goes at the top. This is because it is the most important one.

The **build-backend** key points to a module that knows how to build source distributions and wheels from the project. The **requires** field allows specifying *build time* dependencies.

Many projects are built with **setuptools**. There are some new alternatives, like **flit** and **hatch**.

### Plugins

One benefit of the **requires** section in **build-system** is that it can be used to install *plugins*. The **setuptools** package, in particular, can use plugins to modify its behavior.

One thing that plugins can do is to set the version automatically. This is a popular need because version management can often be painful.

### Segue

Before continuing, it is worth reflecting on the nature of "parodies". A *parody of X* is an *instance of X* which exaggerates some aspects, often to the point of humor.

For example, a "parody of a spy movie" *is* a spy movie, even as it riffs on the genre.

### A parody of setuptools plugins

With this in mind, what would a parody of a **setuptools** plugin look like? By the rule above, it has to be a plugin.

The plugin, called **onedotoh**, sets the version to... 1.0.0. In order to be a plugin, it first has to be a package.

A package should have a `pyproject.toml` :

```
[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"

[project]
name = "onedotoh"
version = "1.0.0"

[project.entry-points."setuptools.finalize_distribution_options"]
setuptools_scm = "onedotoh:guess_version"
```

There is a new section: **project.entry-points**. This means that the function **guess_version** will be called as **setuptools** is ready to finalize the distribution options.

The code of **guess_version** is one line:

```
def guess_version(dist):
    dist.metadata.version = "1.0.0"
```

### Version to 1.0.0

Using **onedotoh** is subtle. One problem is writing the **pyproject.toml** **project** section to look like this:

```
[project]
name = "a_pyproject"
version = "0.1.2"
```

The **version** in the **pyproject.toml** will *override* the version from the plugin.

The obvious solution is to remove the **version** field:

```
[project]
name = "a_pyproject"
```

This fails in a different way. Without the **version** in the **project** section, the file is invalid. The **name** will not be used.

The right way to do it is as follows:

```
[project]
name = "a_pyproject"
dynamic = ["version"]
```

This approach explicitly declares the **version** field as dynamic.

A full example will look like this:

```
[build-system]
requires = [
    "setuptools",
    "onedotoh",
]
build-backend = "setuptools.build_meta"

[project]
name = "a_pyproject"
dynamic = ["version"]
```

Finally, the version is automatically set to **1.0.0**.

### Wrap up

The **setuptools** plugin can still be used with modern Python packaging, as long as relevant features are explicitly declared as "dynamic." This makes a field rife for further experimentation with automation.

For example, what if, in addition to guessing the *version* from external metadata, it would guess the name as well, using the **git remote** URL?

--------------------------------------------------------------------------------

via: https://opensource.com/article/22/9/modern-python-packaging-setuptools-plugins

作者：[Moshe Zadka][a]
选题：[lkxed][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出

[a]: https://opensource.com/users/moshez
[b]: https://github.com/lkxed
[1]: https://opensource.com/sites/default/files/lead-images/coffee_python.jpg