Fill in authors filed during uv init

[j178]

Summary

Fill in the authors field of pyproject.toml by fetching author info from Git.

Resolves #7718

[edmorley]

Hi! For non-packaged application project types, I would probably end up deleting the author info most of the time.

What do you think about only adding it for libraries + package=true app types? ie: Putting this block inside an if package conditional?

[zanieb]

That seems reasonable to me, I think. If we do this, we should add an --authors flag too and allow it to force them to be added.

[j178]

Regarding --authors, shoule we enable it to accept a value? For example: uv init --authors 'Alice <alice@exmaple.org>' or uv init --authors Alice.

[zanieb]

That's... a good question. It makes sense to allow providing the authors, but also it breaks our typical --no-<flag> / --<flag> pattern. I think we'd need like... --authors git as a special value that says fetch from git?

[j178]

or rename this flag as something like --fill-authors / --no-fill-authors and keep --authors for future usage?

[zanieb]

I'm hesitant to introduce a bunch of flags for this. I'll do some thinking out loud. Typically, we use singular names for options that can be repeated so... --author <name> --author <another name> makes sense to me. Then... --no-authors with a --no-author alias to disable detection? Then we're left with "I want the author to be derived from somewhere even if it's an app" which could be like --force-author or we can reuse --author and add a special key like auto. This is sort of nice because we can add more special keys like git, os, etc. for various author sources? This would let you force read from a source e.g. uv init --vcs git --author os which would otherwise be another new flag like --author-from? I think collisions are pretty unlikely but it does make the flag less self-documenting.

I shall seek another opinion here. cc @BurntSushi

[BurntSushi]

I guess my initial reaction here is that it's not worth changing this flag's behavior based on library versus application. It's not immediately obvious to me why we would make that distinction by default. If folks don't want author information, then instead of deleting it after-the-fact, they can do --no-authors.

Otherwise, how far do we want to go with uv init being an interface for writing metadata values to pyproject.toml? If we just want it to be something that tries to infer things with reasonable defaults, then we might not need to expose functionality like --author BurntSushi.

Failing all of that, I like your approach @zanieb. I might use infer-git instead of just git for example. Or something like that.

[zanieb]

I guess my initial reaction here is that it's not worth changing this flag's behavior based on library versus application. It's not immediately obvious to me why we would make that distinction by default

I guess I like sensible defaults. I don't think the default has much bearing on the flag name though, we still need both toggles for consistency with the rest of our CLI.

Right now we don't really support passing metadata directly, but I think we generally should in the future so I want to design in a way that we won't regret.

[edmorley]

I guess my initial reaction here is that it's not worth changing this flag's behavior based on library versus application. It's not immediately obvious to me why we would make that distinction by default. If folks don't want author information, then instead of deleting it after-the-fact, they can do --no-authors.

For me, the reason why I wouldn't want authors (or any other optional fields related to packaging) defined in a pyproject.toml for an app project type, is that if the package doesn't have a build backend and isn't being published to PyPI, then it's extra clutter/something to understand/keep up to date that isn't adding any value. (So really this is more about build backend/publishing vs not, rather than app vs library.)

Users could of course delete those fields afterwards, but they'd have to know that they were optional or else be willing to try deleting them and seeing if something breaks (and hoping that the tool's schema validation is solid enough that it gives me a suitable upfront error message rather than something silently breaking later).

Would a compromise that could keep uv init simpler (and avoid the need to support multiple VCSes and OS username lookup etc) be to instead not populate authors at all in uv init and instead have uv publish handle making the package "publish ready" wrt best practices etc (eg prompting if metadata not filled out).

[zanieb]

What if the VCS isn't Git?

[j178]

We could just use Git as a source of information (a common one), it is valid information even if current VCS is not Git.

[j178]

Is it worthwhile to add a new dependency like whoami or users to fetch the OS username as a fallabck method?

[zanieb]

I think it's valuable to use the information from the relevant VCS — so if you say not to use Git we shouldn't fetch information from it or if you say to use Mercurial the author information should come from there.

We could consider adding OS-level author information fetches, but let's do that separately than this.

[j178]

I'll go with --author-from auto|git|none:

#[derive(Debug, Default, Copy, Clone, clap::ValueEnum)]
pub enum AuthorFrom {
    /// Fetch the author information from some sources (e.g., Git) automatically.
    #[default]
    Auto,
    /// Fetch the author information for Git configuration only.
    Git,
    /// Do not infer the author information.
    None,
}

[zanieb]

Thank you!

[dpprdan]

I am trying to get the authors field written by uv init, but without success so far. What am I doing wrong?

dan@DP:~/projects/test-uv$ uv version
uv 0.4.20
dan@DP:~/projects/test-uv$ git config --get user.name
Daniel Possenriede
dan@DP:~/projects/test-uv$ ls -a
.  ..
dan@DP:~/projects/test-uv$ uv init --author-from auto
Initialized project `test-uv`
dan@DP:~/projects/test-uv$ cat pyproject.toml
[project]
name = "test-uv"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.12"
dependencies = []
dan@DP:~/projects/test-uv$ rm -r {*,.*}
dan@DP:~/projects/test-uv$ uv init --lib
Initialized project `test-uv`
dan@DP:~/projects/test-uv$ cat pyproject.toml
[project]
name = "test-uv"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.12"
dependencies = []

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

[j178]

@dpprdan Can you show the output of uv init -v --lib and git --version?

[dpprdan]

@j178 Sure

dan@DP:~/projects/test-uv$ uv init -v --lib
DEBUG uv 0.4.20
DEBUG Searching for default Python interpreter in managed installations or system path
DEBUG Searching for managed installations at `/home/dan/.local/share/uv/python`
DEBUG Found `cpython-3.12.3-linux-x86_64-gnu` at `/usr/bin/python3` (search path)
WARN Failed to get author from git: No author information found
DEBUG Writing Python versions to `/home/dan/projects/test-uv/.python-version`
Initialized project `test-uv`
dan@DP:~/projects/test-uv$ git --version
git version 2.43.0

dan@DP:~/projects/test-uv$ git config --global user.name
Daniel Possenriede
dan@DP:~/projects/test-uv$ git config --global user.email
me@example.com

[dpprdan]

FWIW this is on Ubuntu 24.04 on WSL.

[bluss]

Seems like the git config --get/git config get command is not a stable interface - or --get is the variant that has been there longer.

Compare

• https://git-scm.com/docs/git-config/2.47.0
• https://git-scm.com/docs/git-config/2.32.3

[dpprdan]

I think that's it. git config get was apparently introduced in v2.46.0 (vs v.2.45.0).

With v2.43.0 I see

dan@DP:~/projects/test-uv$ git config get user.name
fatal: not in a git directory    # well of course, it is not yet initialised.
dan@DP:~/projects/test-uv$ git config --get user.name
Daniel Possenriede

So better use git config --get for backwards compatibility?

[zanieb]

On it!