Add `--bare` option to `uv init` #11192

zanieb · 2025-02-03T19:27:53Z

People are looking for a less opinionated version of uv init. The goal here is to create a pyproject.toml and nothing else. With the --lib or --package flags, we'll still configure a build backend but we won't create the source tree. This disables things like the default description, author behavior, and VCS.

See

zanieb · 2025-02-03T19:56:07Z

crates/uv/src/settings.rs

@@ -245,17 +249,21 @@ impl InitSettings {
            .map(|fs| fs.install_mirrors.clone())
            .unwrap_or_default();

+        let no_description = no_description || (bare && description.is_none());


This is a little dubious (implementation-wise), but I didn't want to get sucked into refactoring the description handling.

zanieb · 2025-02-03T19:56:50Z

I'll want to add some prose documentation too, but let's see where this goes first.

zanieb · 2025-02-03T20:19:05Z

Also open to another name? I'm not sure what though.

Some people in the linked issues think this should be the default and everything else should be opt-in. I'm a little hesitant about that.

Gankra · 2025-02-03T21:02:26Z

Some people in the linked issues think this should be the default and everything else should be opt-in. I'm a little hesitant about that.

I do think this flag/mode is a good baseline for other flags to opt back into features. (--bare --vcs=git ...).

Gankra

Don't have a strong opinion of the name but the impl seems reasonable.

Gankra · 2025-02-03T21:05:32Z

crates/uv-cli/src/lib.rs

@@ -2574,9 +2581,13 @@ pub struct InitArgs {
    pub r#script: bool,

    /// Set the project description.
-    #[arg(long, conflicts_with = "script")]
+    #[arg(long, conflicts_with = "script", overrides_with = "no_description")]


Gankra · 2025-02-03T21:12:15Z

crates/uv/src/commands/project/init.rs

-        generate_package_scripts(name, path, build_backend, true)?;
+        if !bare {
+            generate_package_scripts(name, path, build_backend, true)?;
+        };

        // Initialize the version control system.
        init_vcs(path, vcs)?;


Wait hold on shouldn't these be wrapped too (in a few places?)

It happens up at https://github.com/astral-sh/uv/pull/11192/files#diff-a459ffa6a304d440657379d39bdef792a801589e6f6cbf1ae01b50754ab5fa98R262

A little questionable, but makes the --vcs git behavior easier.

edmorley · 2025-02-03T21:13:59Z

crates/uv-cli/src/lib.rs

@@ -2518,6 +2518,13 @@ pub struct InitArgs {
    #[arg(long, conflicts_with = "script")]
    pub name: Option<PackageName>,

+    /// Only create a `pyproject.toml`.
+    ///
+    /// Disables creating extra files like `README.md`, the `src/` tree, `.python-version` files,


I wonder whether --bare should still create a .python-version file (if one doesn't already exist), given how integral it is to the deterministic operation of uv? It seems like most of the feedback about unwanted files/content were about the .py files and directory nesting, rather than the .python-version file - so people might be fine with it left in?

People are sort of constantly complaining about the .python-version file actually :/

It don't think it's required for reasonably deterministic action if you have a requires-python in your project. You may be on a different version than someone else, but the lockfile will be consistent.

People are sort of constantly complaining about the .python-version file actually :/

Yeah I've seen quite a few comments, but from what I remember they were in other issues (not about uv init defaults), and generally were about lack of understanding why the seemingly duplicate concepts were needed.

I think longer term perhaps campaigning for an additional Python version field to be added to the pyproject.toml spec would resolve the "why do I need another file" concerns, but for now I think having a pinned Python version via a .python-version file really is still important. Otherwise the day after uv adds support for eg Python 3.14, some developers on a project will end up using Python 3.14 (with lack of wheels), whereas others on their team (who may not have updated uv yet) could still be using Python 3.13 etc - leading to only some people seeing build failures (due to building from source), CI failures, lack of dev-prod parity etc.

It's very likely I'm going to make a missing .python-version file a hard error when deploying a uv app on Heroku for example.

Yeah, I think your take is fair.

My primary concern is that it doesn't make much sense to teach --bare if it does more than just create a pyproject.toml with standards-compliant fields. I'd rather add opt-in support via --pin-python and suggest using it.

It seems feasible that there'd be interest in a standard for a Python version pin in the pyproject.toml; especially now that there are dependency groups that do not require [project] metadata. I'm not excited about trying to pitch it though :D I agree this is the obvious long-term solution over a non-standard .python-version file.

This MR contains the following updates: | Package | Update | Change | |---|---|---| | [astral-sh/uv](https://github.com/astral-sh/uv) | patch | `0.5.27` -> `0.5.29` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>astral-sh/uv (astral-sh/uv)</summary> ### [`v0.5.29`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#0529) [Compare Source](astral-sh/uv@0.5.28...0.5.29) ##### Enhancements - Add `--bare` option to `uv init` ([#11192](astral-sh/uv#11192)) - Add support for respecting `VIRTUAL_ENV` in project commands via `--active` ([#11189](astral-sh/uv#11189)) - Allow the project `VIRTUAL_ENV` warning to be silenced with `--no-active` ([#11251](astral-sh/uv#11251)) ##### Python The managed Python distributions have been updated, including: - CPython 3.12.9 - CPython 3.13.2 - pkg-config files are now relocatable See the [`python-build-standalone` release notes](https://github.com/astral-sh/python-build-standalone/releases/tag/20250205) for more details. ##### Bug fixes - Always use base Python discovery logic for cached environments ([#11254](astral-sh/uv#11254)) - Use a flock to avoid concurrent initialization of project environments ([#11259](astral-sh/uv#11259)) - Fix handling of `--all-groups` and `--no-default-groups` flags ([#11224](astral-sh/uv#11224)) ##### Documentation - Minor touchups to the Docker provenance docs ([#11252](astral-sh/uv#11252)) - Move content from the `mkdocs.public.yml` into the template ([#11246](astral-sh/uv#11246)) ### [`v0.5.28`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#0528) [Compare Source](astral-sh/uv@0.5.27...0.5.28) ##### Bug fixes - Allow discovering virtual environments from the first interpreter found on the `PATH` ([#11218](astral-sh/uv#11218)) - Clear ephemeral overlays when running tools ([#11141](astral-sh/uv#11141)) - Disable SSL in Git commands for `--allow-insecure-host` ([#11210](astral-sh/uv#11210)) - Fix hardlinks in tar unpacking ([#11221](astral-sh/uv#11221)) - Set base executable when returning virtual environment ([#11209](astral-sh/uv#11209)) - Use base Python for cached environments ([#11208](astral-sh/uv#11208)) ##### Documentation - Add documentation on verifying Docker image attestations ([#11140](astral-sh/uv#11140)) - Add `last updated` to documentation ([#11164](astral-sh/uv#11164)) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).

zanieb added the cli Related to the command line interface label Feb 3, 2025

Add --bare option to uv init

26fc3a1

zanieb force-pushed the zb/bare branch from 2896a51 to 26fc3a1 Compare February 3, 2025 19:28

zanieb commented Feb 3, 2025

View reviewed changes

zanieb marked this pull request as ready for review February 3, 2025 19:56

zanieb requested a review from charliermarsh February 3, 2025 19:57

Gankra approved these changes Feb 3, 2025

View reviewed changes

Gankra reviewed Feb 3, 2025

View reviewed changes

edmorley reviewed Feb 3, 2025

View reviewed changes

Add docs

100e8b5

zanieb merged commit acbbb2b into main Feb 5, 2025
73 checks passed

zanieb deleted the zb/bare branch February 5, 2025 16:12

BrewTestBot mentioned this pull request Feb 6, 2025

uv 0.5.29 Homebrew/homebrew-core#206700

Merged

nathanjmcdougall mentioned this pull request Feb 7, 2025

Refactor to use uv init --bare nathanjmcdougall/usethis-python#274

Closed

zanieb mentioned this pull request Feb 8, 2025

FR: uv init option to specify alternative filename to hello.py #7782

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add `--bare` option to `uv init` #11192

Add `--bare` option to `uv init` #11192

zanieb commented Feb 3, 2025 •

edited

Loading

zanieb Feb 3, 2025 •

edited

Loading

zanieb commented Feb 3, 2025

zanieb commented Feb 3, 2025

Gankra commented Feb 3, 2025

Gankra left a comment

Gankra Feb 3, 2025

Gankra Feb 3, 2025

zanieb Feb 3, 2025

edmorley Feb 3, 2025

zanieb Feb 3, 2025

edmorley Feb 3, 2025 •

edited

Loading

zanieb Feb 3, 2025

Add --bare option to uv init #11192

Add --bare option to uv init #11192

Conversation

zanieb commented Feb 3, 2025 • edited Loading

zanieb Feb 3, 2025 • edited Loading

Choose a reason for hiding this comment

zanieb commented Feb 3, 2025

zanieb commented Feb 3, 2025

Gankra commented Feb 3, 2025

Gankra left a comment

Choose a reason for hiding this comment

Gankra Feb 3, 2025

Choose a reason for hiding this comment

Gankra Feb 3, 2025

Choose a reason for hiding this comment

zanieb Feb 3, 2025

Choose a reason for hiding this comment

edmorley Feb 3, 2025

Choose a reason for hiding this comment

zanieb Feb 3, 2025

Choose a reason for hiding this comment

edmorley Feb 3, 2025 • edited Loading

Choose a reason for hiding this comment

zanieb Feb 3, 2025

Choose a reason for hiding this comment

Add `--bare` option to `uv init` #11192

Add `--bare` option to `uv init` #11192

zanieb commented Feb 3, 2025 •

edited

Loading

zanieb Feb 3, 2025 •

edited

Loading

edmorley Feb 3, 2025 •

edited

Loading