Package by default: Add in preview

[konstin]

Switch the (preview) default for uv init to a src-package. The package by default has an entrypoint by the name of the package that can be run with uv init foo.

There's effectively three layouts with this change:

• package with entrypoint (packaged application, the default)
• package without entrypoint (pure lib)
• flat main.py application (pure app)

These are selected from among the existing --app/--lib and --package/--no-package flags, as to not cause too much churn. --build-backend still implies --package, with --app --build-backend doesn't change. --bare doesn't add a build system by default.

Testing is a bit awkward, cause there's now all the stable tests and a separate test for the preview behavior, while we'll have to update the stable tests upon stabilization. You can see the effect of stabilization in #19197.

kind	package	template
(default)	(default)	entrypoint + package exposing hello()
(default)	--package	entrypoint + package exposing hello()
(default)	--no-package	main.py with main()
--app	(default)	main.py with main()
--app	--package	entrypoint + package exposing hello()
--app	--no-package	main.py with main()
--lib	(default)	package exposing hello()
--lib	--package	package exposing hello()
--lib	--no-package	Error: libraries are always packaged

Navigation

There are three branches:

• main <- konsti/package-by-default
  Package by default: Add in preview #17841
• konsti/package-by-default <- konsti/package-by-default-doc-changes
  Package by default: Update documentation #19026
• konsti/package-by-default <- konsti/package-by-default-stabilize
  Package by default: Stabilize preview feature #19197

Open Decided design questions

• Should the default layout fill out the authors table?
  No, the authors field isn't helpful here.
• Should --bare also create a (by itself broken) build system by default, without setting --package or --build-backend?
  No, we want something that works, and not creating a build backend is very bare. It's slightly inconsistent that effectively --bare is no-package by default, but that's better than the alternatives and explainable as --bare being no-most-things.

[codspeed-hq]

Merging this PR will not alter performance

✅ 13 untouched benchmarks

---

_{Comparing konsti/package-by-default (39c1221) with main (3b8e3ca)}

[konstin]

Flagging: Should bare with a build backend populate authors?

[zsol]

overall LGTM but there are a few things we should address in here

[zsol]

nit: don't use Old/New, they quickly become confusing :) I'd go with ApplicationWithPackageInitOff and LibraryWithPackageInitOff

[konstin]

This should only be temporary, https://github.com/astral-sh/uv/pull/19197/changes removes the nomenclature entirely, the idea is more like <style>ToBeRemoved and <style>ToBecomeTheDefault

[zsol]

I realize this is what you highlight as a question in the PR summary, so let's discuss: What's the downside of filling this out by default?

[konstin]

It's more metadata to maintain, especially since it's filled with whatever name and mail the person who did uv init had configured. We can't infer actual team information, and if it's not distributed as a package, there doesn't seem to much use in the package authors field. It's also taking a lesson from Cargo, which wanted to deprecate the authors field entirely but eventually settled on making it optional and not filling it by default: https://rust-lang.github.io/rfcs/3052-optional-authors-field.html. Python didn't make this same decision, but the considerations of the RFC apply to Python equally.

[zsol]

Sounds good to me!

[zsol]

we don't call this in BareWithBuildSystem, which will probably result in a broken configuration with e.g. maturin or scikit. Is that intentional? If so, maybe capture that somewhere?

Edit: I now realize this is another thing you call out, so my opinion is that we shouldn't generate broken configuration if we can help it

[konstin]

Does this mean we should error for uv init --lib --bare or uv init --package --bare? (Given that we shouldn't ignore --lib/--package)

[zsol]

Do you think it's possible to generate something that's not broken? If not, then erroring out would be fine

[konstin]

There's two aspects here:

Stable already allows uv init --bare --package, which creates a [build-system] table without the associated files. Not supporting this anymore would be a regression.

It seems fine to not create a build system with --bare by default, as --bare doesn't create most things we usually create.