[scope] Should we aim for multiple build frontends/backends or nah

[sneakers-the-rat]

Came up in: https://github.com/pyOpenSci/pyos-package-template/pull/59

I had sorta had the background assumption that we would eventually be wanting to be able to choose between packaging tools, but i should probably check that first.

Hatch does a bunch of awesome stuff that rocks. As both an educational, as well as functional tool tho, I think it would be cool to find our way into supporting multiple package/build tools. e.g. in our packaging guide, if we could use this to autogenerate the same demo across all the packaging tools to show comparisons that would be super rad (currently all the docs like this are hardcoded, and thus there can be a bit of impedance mismatch between toy examples and reality). It also would make it a tool useful for more ~crusty[^self]~ ~opinionated[^shade]~ experienced developers who already have strong opinions about how they like things but haven't made a tool for that yet[^me].

It would take some work to make the config ui pleasant, and we would need to also invest in some tooling in our templates, so this is a scope question for the life of the project, not a "let's do this right now" request.

[^self]: self description intended [^shade]: to thine own self only doth i cast shade [^me]: me, it is me and i am being selfish because i have wanted to make something like this for myself for so long but making it with all of you is so much more fun and better than i could do.

[Midnighter]

I could see extending the template to a build tool for compiled extensions, but otherwise would want to keep it as close as possible to the recommendations of the pyOS packaging guide. There were some folks advertising another template that aims to be more comprehensive. I'm leaning more towards not going too far in that direction.

[sneakers-the-rat]

i guess i also have a sort of mutating view of the guide, where we have different senses of guide (e.g. the tutorials vs. the guide proper) and over time we can keep the "single track if you just wanna get poppin" but also choose your own adventure, linger here awhile if you want to know more about the range of package managers, what each license does, the different ways of making extension modules, etc.

i really like the suggestion from chat of having "easy mode" and "advanced mode" - one that's purpose built to be exactly the guide rec out of the box and another that spirals off into the python boilerplate fever dream we have all been tempted to make but never dared - maybe one way of describing what i'm thinking is building the strict mode as a subset of advanced mode with tests to defend its strictness.

it's late and i'm not in engineer mode, but wouldn't it be very cool to be able to e.g. traverse the guide and pick different routes through the topics that match your style, and then that is generating you a config file you can feed into the template and boom all your faves are now real. and vice versa, if someone has an opinionated pick of tools, they can share their config and be like "here's the guide to my business SaaS setup, and here's a different one for my sprawling hobby project namespace package monorepo"

[blink1073]

I share @Midnighter's concern. The majority of the feedback I've seen about the Python Packaging User Guide is that having too many choices about tools is adding too much cognitive load to the user. I think having one or two opinionated options that the user can choose from is a strength of the pyOpenSci approach to date.

[Midnighter]

wouldn't it be very cool to be able to e.g. traverse the guide and pick different routes through the topics that match your style, and then that is generating you a config file you can feed into the template and boom all your faves are now real

This would be so cool!

[sneakers-the-rat]

to be clear i am not saying we clutter everything and induce choice paralysis - definitely a big fan of the "tell me what's the best way to do stuff" mode. All i'm saying is that we can do both :) you can travel along the straight and narrow line in the x dimension, but if you want to come back later and see more about topic at a position on the x numberline, you can browse around through some of the weeds off the side of the road in the y direction

[lwasser]

Hi! a few notes! Scientific Python’s cookie offers tons of options—Henry mentioned up to 12+ backends! And to echo @blink1073 comment, at last year’s SciPy packaging, BoF, people kept mentioning that, for some, that cookie presented many options (TMO). Our goal is to reduce TMO with clear, opinionated choices that help users succeed.

Let’s focus on a few curated paths that minimize decision-making. Down the line, we could add / create a template for compiled builds, possibly using Meson or Hatch + plugins (@ucodery got C builds working with Hatch at PyCon this past spring!).

Simplifying choices here helps users achieve quick wins and build confidence. It also provides a nice complement to the work Henry has already done as well!

Yesterday, we had high success rates using this minimal version of this template! It was awesome! 🚀 which is to say that i REALLY appreciate all of the thought and work going into this!!

[sneakers-the-rat]

I think I will have to make an example of what im talking about, because looking at that cookiecutter I understand totally what folks would be worried about.

To reiterate again, I am not saying we remove the one short path to best practices, just have an "advanced mode" that is possible too. Ig the only advocacy Im having is that I think we can do that in the same template and reuse the templating tools instead of having two templates that duplicate some code and labor.

Im happy to chill and enjoy hatch for now tho, no hurry :)