Surviving pip updates which are enforcing pyproject.toml

[jpic]

Apparently, custom entrypoints are not working anymore with pip install -e, only console_scripts was maintained. Also, pip install -e seems to actually pull releases of dependencies which I already had installed with pip install -e which is ridiculous.

Anyway, they seem to have decided to break BC with setup.py and are generally causing havoc in our setupmeta packages, requiring pyproject.toml, don't remember the details.

Have you followed what's happening there?

Is this the new way for using setupmeta?

[build-system]
requires = ["setuptools>=64", "setupmeta"]
build-backend = "setuptools.build_meta"

[project]
name = "artinator"
dynamic = ["version"]
authors = [{name = "James Pic", email = "jamespic@gmail.com"}]
description = "CLI tool"
readme = "README.md"
license = {text = "MIT"}
keywords = ["cli"]
requires-python = ">=3.6"
dependencies = [
    "cli2>=v6.0.0-rc13",
    "litellm",
]
urls = {Homepage = "https://github.com/yourlabs/artinator"}

[project.entry-points.artinator]
fileread = "artinator.tool:FileRead"

[project.scripts]
artinator = "artinator.cli:cli.entry_point"

[tool.setuptools.packages.find]
where = ["."]
include = ["artinator*"]

[tool.setupmeta]
root = "."
tag = "v{version}"
versioning = "dev"

If setup.py goes away, are we going to call python -m setupmeta instead to output generated information?

[zsimic]

With pyproject.toml, everything becomes static, so there won't be any opportunity for setupmeta to autofill anything (unless one explicitly declares fields as dynamic). So what is left is just the versioning feature.

I am considering contributing to setuptools-scm a way to handle versioning targeted towards continuous deployment (the only thing it is sorely missing compared to setupmeta's versioning).

setuptools-scm has the advantage of being more "official" (it's in the pypa github), and it has been upgraded to work properly with pyproject.toml.

WDYT? Do you find any other feature that you'd be missing from setupmeta?

To recap:

• Auto-fill does not make sense for pyproject.toml (more trouble than it's worth)
• Versioning is perhaps slightly simpler in setupmeta, but setuptools-scm can reasonably do all controlled versioning strategies, all it's missing is a good versioning strategy for continuous-deployment

[zsimic]

For your case, since you're using dev strategy, you are not in the continuous deployment case, so it should be as easy as:

[build-system]
requires = ["setuptools>=64", "setuptools-scm"]
...
[project]
dynamic = ["version"]
...
[tool.setuptools_scm]
local_scheme = "dirty-tag"

This would turn on setuptools-scm, and it will use the default versioning scheme guess-next-dev which is very similar to setupmeta's dev (it just doesn't mark dirty versions properly by default, hence you do have to tell it to do that)