Support Poetry as Hatch alternative

[slobentanzer]

Would it make sense to include Poetry as an option? I tend to use that almost always, because it is quite safe for version dependencies and I don't need the multi-env functionalities of Hatch.

[lwasser]

hi there @slobentanzer . Great question!

The goal of this template is to provide 1 opinionated way to make a Python package. We worked closely with the core packaging teams and maintainers and the community and landed on Hatch (which you will see used in our tutorials).

We ruled out poetry for a few different reasons, including they weren't closely following the current peps at the time, and it doesn't support other build backends (we have a lot of scientists creating packaging that require compilation build steps).

Adding a new front end is not within the scope of this template. However, in the future, if we decide as a community that another tool is better and preferred by the broader community, we certainly want to consider it!

Each tool has different features and benefits. We're trying to collectively carve out a path for beginners and those who don't want to become packaging experts to make packaging simpler!

[slobentanzer]

Makes sense. However, having simple packaging was exactly the reason why I went with Poetry though. It may be a bit of ignorance on my behalf, but hatch seemed a bit more complex with the different envs.

I have been using the copier workflow of this repo for two projects now (can confirm it works well), and both times have manually migrated the pyproject.toml configurations from hatch to poetry. This was not such a big effort in each case, and limited to the pyproject.toml; so unless there is something I don't see, this should be fairly simple to include as an option (hatch can still be the default).

Not exactly sure I understand what you mean by "front end"; my suggestion was just to add one more choice to the copier setup that asks "Hatch or Poetry?". Feel free to clarify if there are some complexities I don't get. :)

[slobentanzer]

Maybe to clarify further: this suggestion is (in my view) at the same level as the options that let users decide between Sphinx and mkdocs-material, or GitHub vs GitLab as a platform.

[lwasser]

Hey there, @slobentanzer. Let's take a step back, and rather than focusing on front end tools like Poetry, pdm, flit, etc tools, let's focus on the complexity that you encountered.

Hatch, by default (and potentially our template), creates a pyproject toml that highlights all of the features it offers. This includes matrix environments and such. Things that people who are newer to packaging and also who might have other tools and workflows that they prefer (like nox!) might not need.

Can you be specific about what pieces made you want to switch?

At it's core, Hatch can be straightforward, which is why we selected it in that you can use

hatch init
hatch build
hatch ....

And more importantly, it allows you to use different backends like meson-python, which is important for any scientist creating software that isn't pure python.

The matrix environments and other nox/tox like features are optional.

Let's focus on that first.

Adding additional front ends here is not in scope for this guide (I'm happy to explain further). Simplifying so it better aligns with our tutorials absolutely is! Our tutorials do not use this template yet because I want to spend a bit more time looking at this first with a beginner's lens.

[slobentanzer]

Thanks, that page is really helpful. On what made me want to switch: it wasn't the hatch API per se, it was the knowledge that I felt I would have to acquire in order to feel comfortable replacing my Poetry workflow. If I see that a build manager has options for multi-env and other things that I am not familiar with, I feel the need to know at least the basics. Looking into it, it seemed that the additional functionality wasn't even required for my applications, so the learning curve of switching over wasn't justified for me. A minor aspect is that we want our packages to be widely usable, which seems easier using the most stable and popular environment manager (and lock files).

Is there a difference for you between a guide and a template? As you phrase your responses, it seems to me that this has some tutorial elements to it; my impression was that this package was supposed to be a flexible template for setting up real state-of-the-art projects (at least that's what I tried to use it for). Is that not a use case? I may have gotten that wrong then.

The request in this issue was mainly selfishly motivated; when I use this template (which does help indeed), I always need to go and migrate the pyproject.toml to Poetry. Thus the suggestion to make it an option (which would also make it easier for others to use Poetry, in addition to saving me the trouble). But if that's not in scope, no problem. I can also create my own fork and change it there. :)