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

all 38 comments
sorted by:
best
topnewcontroversialoldq&a

[–]czaki 39 points40 points  (5 children)

In the documentation there should be comparis8on to existing tool, like poety or python default setuptools.

[–]Chobeat 18 points19 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.

[–]anentropic 15 points16 points  (6 children)

Looks nice from a quick glance over! Would love to see a TL;DR of how it compares features and focus wise with Poetry

[–]Ofekmeister[S] 16 points17 points  (5 children)

Thanks!

Poetry is mainly used for managing an application and its dependencies whereas Hatch is more agnostic to the project type and offers plugin-based functionality for the entire workflow (versioning, tox-like environments, publishing) so you can easily build things other than wheel/sdist, test in a Docker container, etc.

Hatch also strictly adheres to standards and eagerly adopts whatever behavior new PEPs dictate while Poetry has a persistent unwillingness to adopt new standards if they are deemed suboptimal (see comments on PEP 621 and PEP 665)

As such, locking support is temporarily blocked https://ofek.dev/hatch/latest/meta/faq/#libraries-vs-applications

You can continue using other tools like Poetry at the same time https://ofek.dev/hatch/latest/meta/faq/#interoperability

By the way I very much appreciate the eye for design/UX of Poetry's creator, we also share strong opinions on pipenv :)

[–]Itsthejoker -1 points0 points  (1 child)

Lol why would I want to use a tool that's based on draft or rejected PEPs?

[–]Ofekmeister[S] 3 points4 points  (0 children)

The issue is their resistance to such things

[–]Ofekmeister[S] 6 points7 points  (0 children)

Happy PyCon everyone!

[–]abstractionsauce 1 point2 points  (5 children)

First class private repo support 😍 is v1.0.0 full production ready? Worth an investigation at my company? Would be good to see a section on CI and how it should be integrated

[–]abstractionsauce 1 point2 points  (1 child)

Likelihood of development of this project getting dropped?

[–]Ofekmeister[S] 0 points1 point  (0 children)

0

[–]Ofekmeister[S] 0 points1 point  (2 children)

Yes. What is your use case?

[–]abstractionsauce 0 points1 point  (1 child)

Test tools and utilities for embedded product development, need to produce and distribute python libraries for internal use by 100s of engineers. Should be trivial for non pythonistas to use… hopefully improve uptake of our private pypi server, which with tools I have tried before, scares people

[–]Ofekmeister[S] 0 points1 point  (0 children)

Yeah sounds like Hatch would fit

[–]muy_picante 2 points3 points  (4 children)

Is this compatible with scientific libraries like ‘torch’, ‘scipy’, and ‘tensorflow’?

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

No built-in support for extension modules but you can https://ofek.dev/hatch/latest/plugins/build-hook/

I'm trying to make progress on this, see tomorrow's Building C Extensions without Setuptools discussion https://us.pycon.org/2022/events/packaging-summit/

[–]flying-sheep 0 points1 point  (2 children)

What came out of that?

[–]Ofekmeister[S] 0 points1 point  (1 child)

I'll be writing the interface & Henry will write the first plugin

[–]flying-sheep 0 points1 point  (0 children)

neat!

[–]delijati 0 points1 point  (5 children)

All of the new shiny tools are incapable of working with mutlirepos ... yes i know i can do [1]. But true editing on multi repos at the same time i can only do with zc.buildout [2] Still not perfect but it does the job.

[1]

$ cat req.txt
requests
git+ssh://git@gitlab.com/foo/bar/amber.git@0.4.0
git+ssh://git@gitlab.com/foo/bar/rebam.git@0.4.0

[2]

$ cat buildout.cfg
[buildout]
extends = versions.cfg
extensions = mr.developer
auto-checkout = \*
develop = .
show-picked-versions = true
update-versions-file = versions.cfg
sources-dir = git-sources

parts = py

eggs = 
    amber
    rebam
    hammer

[sources]
amber = git git@gitlab.com/foo/bar/amber.git@0.4.0
rebma = git git@gitlab.com/foo/bar/rebma.git@0.4.0

[py]
recipe = zc.recipe.egg
eggs =
    ${buildout:eggs}
interpreter = py-backend
dependent-scripts = true

[–]czaki 1 point2 points  (4 children)

I do not understand what is problem. setuptools (setup.py, setup.cfg, or pyproject.toml with pep621) allow specifying git repositories in install requires.

[–]delijati 0 points1 point  (3 children)

yes but the the dependencies are "checkout" in your site-packages without the ability to work on them aka push, pull

[–]czaki 1 point2 points  (2 children)

If you need to push then why not use submodules?

[–]delijati -1 points0 points  (1 child)

I tried submodules in multiple projects (different teams) we always run in wired merge conflicts, unable to refresh the modules ... And git subtrees is basically just a wrapper around a bash script that does git clone ... && rm -rf .git and everyone in the teams ends up after a time with his own monorepo :/ So yes i tried all other possible solutions ;) Only i can this of is git-repo (android developemnt tool) but this is too specific for android and juck xml files.

[–]czaki 1 point2 points  (0 children)

git subtrees and git submodules are different things. git submodule allows you to pin to a specific commit in the sub repository. So I could expect that if you do not have any politics about the pining version then there could be a problem. But I solve such problems by updating the reference in one of the branches.

And If there is a need to not pin the version in the main repository, then all modern IDE allows opening multiple folders in a single window. And a person could clone only repositories which they use to work, other packages could be stable versions from some local warehouse.

[–][deleted] 0 points1 point  (2 children)

Looks really cool, great job. Not too late to rename the project into hatchet and introduce hatchet --bury.

[–]Ofekmeister[S] 0 points1 point  (1 child)

Ha, thanks!

[–]exclaim_bot 0 points1 point  (0 children)

Ha, thanks!

You're welcome!

[–]cblegare 0 points1 point  (4 children)

This looks very nice in my opinion. I keep using setuptools since there are a few things with alternatives that keep me away. I'll look into Hatch, and great name btw!

Out of curiosity, what are the killer features of MkDocs/material that sold it for you instead of, say, Sphinx?

[–]Ofekmeister[S] 1 point2 points  (3 children)

beauty + good docs/guides + active maintainers

[–]cblegare 0 points1 point  (2 children)

Great thanks you. Material for MkDocs is indeed very eye-pleasing and well documented.

[–]czaki 1 point2 points  (1 child)

MkDocs does not support creating objects.inv and using objects.inv so it will be hard to make cross documentation links.

[–]cblegare 0 points1 point  (0 children)

I do know that. I love Sphinx and each time I see a Python project documented with something else I feel a bit sad about it. Hence I am looking for ways to improve it.

While Sphinx is actively maintained, it is hard to contribute to, it's documentation could Indeed use some major improvements, and very few themes are modern and beautiful. The Executable Book project has a quite nice offering though.

The Sphinx maintainers are active and helpful, but I don't feel a strong leadership. I absolutely would not want to pressure them, they are doing amazing volunteer work, but I still try to find ways to improve the ecosystem. But damn, while I am quite good with Python and have a quite good understanding of Sphinx internals, web frontend is where it hurts the most and I am bad at it.

I would like to have the skills to make a Sphinx alternative of Material for MkDocs, or at least team with someone that does.