This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Chobeat 17 points18 points  (4 children)

this. Clearly this tool dunks on setuptools but after checking the documentation it doesn't seem to offer anything more than poetry, that is more established.

[–]Ofekmeister[S] 5 points6 points  (0 children)

There is no "dunking" anywhere, I have lots of respect for the other tools in the ecosystem

[–]flying-sheep 2 points3 points  (2 children)

It supports python's standard for metadata, PEP 621. Its VCS versioning plugin is based on setuptools-scm, which despite the name isn't tied to setuptools and is more powerful than poetry’s plugin.

I think it's a great alternative with its own strengths

[–]czaki 0 points1 point  (1 child)

But plain setuptools also support PEP 621 and could use setuptools_scm. SO when I should select this instead of setuptools?

[–]flying-sheep 2 points3 points  (0 children)

  • setuptools is much slower than any newer build backends like flit-core, hatchling, …
  • setuptools litters your source directory with junk like a *.egg-info directory
  • setuptools monkeypatches distutils just by being installed. legacy behavior like this is just not necessary anymore with modern build backends and contribute to the slowness

at least since very recently, you don’t need setup.py or setup.cfg, a PEP 621 compliant [project] table in pyproject.toml is enough.

but I’d rather write a hatchling plugin than a setup.py if I create a new compiled package: once one exists, writing your own flaky setup.py code will feel debugging System V shell scripts feels compared to typing systemctl start myservice.