[Documentaton] What makes whey different?

[danieldjewell]

Background

There are a lot of Python package/project management systems (poetry, flit, hatch, and regular setuptools are ones that come to mind quickly). All have their unique qualities and all, more or less, have the same goals.

Enter whey

I just discovered whey. The documentation doesn't really explain how/why whey is different. So I'm left asking myself: Why whey?

Project Goals/Scope

In my experience, it's extremely beneficial to clearly establish the goals/scope of a project. Not only for one's own sanity, but also to help clearly and concretely communicate to others what the project is about. This is especially helpful in open source projects to focus the efforts of contributors and reduce (if not eliminate) superfluous PRs that don't really go in the direction envisioned for the project.

Doing this also helps reduce/prevent scope creep and helps to determine if some feature or functonality should be in the project or should be a sub-project/plugin/etc.

Efficiency / Duplication of Efforts

I like efficiency. I also have a strong distaste for duplicating efforts. (Now that's just me...) I am definitely not going to go rewrite something like numpy or pandas from the ground up. But either (a) improving/adding functionality to the core project or (b) extending the core in some way to add functionality... that's great. Excellent examples of this would be how pint-pandas extends pandas to utilise pint

Differences/Comparison

As a developer, it's not always the most pleasant thing to compare your work or project to others. Yet, others will do it regardless and, at the end of the day, the project lead/originator/inventor is, ultimately, likely the best person to do the comparison (because he/she recognized a need and understands best the differences). There are several examples at the end and I've included a list of questions in a later section.

Humour Is Great (and often based in reality)

The reality, as we know, is that the above XKCD isn't far from the truth... And the very reason why it's funny could be an excellent starting point for a project.

Questions to Consider Answering

Note: @domdfcoding you may have already answered these in your head or maybe not. My suggestion is to write about it so that others can understand. 😀

• What are the goals of whey? What does whey set out to accomplish? What unmet need is whey attempting to solve? What's the scope? (These can always be changed/updated. But having them clearly defined helps to have a baseline so you can decide whether or not to change them.)
• Are there projects that are similar (there are, in this case...)? What do they do? What do they do well? What do they do not so well? What don't they do?
• How does whey compare to these other projects? Features? Capabilities? Goals? Scope? What makes whey different? ... Why (do you think) whey is better?
• What does whey do well? What doesn't whey do so well? (And the latter question can be broken into 2 subparts: What doesn't whey do so well right now [but is planned]? What doesn't whey do so well and isn't in the scope of the project?)
• Roadmap (ties in with scope/goals): Where is whey going? Features? Plans?

As an example, whey's readme indicates

• supports PEP 621 metadata.
• can be used as a PEP 517 build backend.
• creates PEP 427 wheels
• handles type hint files py.typed and *.pyi stubs

Great! So, how do poetry, flit, hatch, and setuptools compare? I don't really know, but I'd like to! 😁

Examples of Answers to some of the above from other projects

• pint's design principles
• python-zstandard State of Project and Comparison
• dbup Philosophy Behind Dbup
• myst-parser Background and explanation
• kopf "vision" and kopf "alternatives"