My initial reaction is that adding an argument for this feels unnecessary. It’s almost as much work to provide the argument as it is to rename the file. I’m gonna defer to @zanieb on this one though.

Fair point. I think my preference here would actually be making uv init generate main.py over hello.py. Should have made that my request! For now, I've implemented this manually in my .zshrc with:

uvi() {
    uv init "$@"
    mv hello.py main.py
}

#7670 is similar but not the same, about picking more commonly preferred defaults

I think we could call it main.py instead — though having a function main in a file main and also having a __main__ file in some cases could be confusing. I'm not attached to the default name of hello.py though. It was mostly intended to be an example file that matched the other init kinds which have a hello command and function.

If it helps as a data-point: From the research I did for the Heroku Python buildpacks [1] (using metrics from many thousands of builds/apps), the most common filenames we see in "single .py file in the root directory" type projects are app.py and main.py. The latter I'm guessing due to guides like the FastAPI tutorial using main.py. The former I'm less certain about, but I know Flask does auto-detection if it finds an app.py - so perhaps that's the reason?

[1]: One of the features of Heroku is that users can git push arbitrary code to their app, and the Heroku build system via the buildpack detection feature will determine which language their app uses, and run the appropriate buildpack to build that app. Whilst the primary signal our Python buildpack checks for is the presence of a package manager file (such as requirements.txt, poetry.lock, and in the future uv.lock etc), it's not uncommon for users to have manually pip installed their dependencies locally and either not created a requirements file at all, or forgotten to Git commit it. So we use additional signals to determine the app's primary language is likely Python (bearing in mind apps can be multi-language, and users can have one-off Python scripts in the repo root that are for development use only), so we can then display a "the package manager file is missing" type error to those apps.

Hello to all! I'm new to issues but want to join the pool of feature requesters! It would be great to have alternative names for the initial .py file, or at least an option to disable creating it at all (--no-hello).

p.s.: Thank you a million for creating such amazing tools like uv and ruff, I just started using them and am already in deep love!! Gonna spread the word across my fellow python devs and enjoyers <3

@artjxm you can disable it with --bare (added in #11192)

Glad you like the tools <3

How do people feel about <project-name>.py vs app.py or main.py? Just wondering as we get close to changing this in v0.6.0 (#11329)

@zanieb I'd much prefer app.py or main.py to <project-name>.py.

@nbbaier Do you have a justification? When you do uv init --package we create a <package> entrypoint so it's uv run <package>. Why not have uv run <package>.py for parity? Why is uv run main.py better?

Similarly, <package>:main may make more sense as a module / function relationship than main:main.

An example counter-point would be cargo new does main.rs

❯ cat example/src/main.rs
fn main() {
    println!("Hello, world!");
}

Wouldn't the equivalent of cargo's src/main.rs be src/foo/__main__.py? That would also then allow python -m foo (I guess similar to cargo run) to work.

@Ravencentric that layout requires a build backend, but is ~what we do with uv init --package. If we created <package>.py, that would allow python -m <package>. For example, this works today

❯ uv init example
Initialized project `example` at `/Users/zb/workspace/uv/example`
❯ cd example
❯ uv run -m hello
Using CPython 3.12.6
Creating virtual environment at: .venv
Hello from example!

@nbbaier Do you have a justification? When you do uv init --package we create a <package> entrypoint so it's uv run <package>. Why not have uv run <package>.py for parity? Why is uv run main.py better?

I honestly don't have much of a justification, to be honest. I'm mostly work with JS/TS, so I'm not used to my main entry points being named <package>.ts, but a consistent <index>.ts.

Fixed in #10369