Feature Request - uv publish recognizes .pypirc file

[geozeke]

Thanks soooooooo much for the work on this amazing tool! I'm in the process of migrating the toolchain for all my Python projects to uv & ruff!

The recently-released publish command is a really welcome addition. When I run it, it's listed as "experimental", so I'm hoping there's still an opportunity for input on the feature. Definitely not an urgent feature need, but It would be great if publish recognized the .pypirc toml file, as specified in the Python Packaging User Guide. Namely:

[distutils]
index-servers =
    pypi
    testpypi
    private-repository

[pypi]
username = __token__
password = <PyPI token>

[testpypi]
username = __token__
password = <TestPyPI token>

[private-repository]
repository = <private-repository URL>
username = <private-repository username>
password = <private-repository password>

This would be like twine, but maybe add a new -r, --repository option that takes the shorthand name from the index servers listed in .pypirc. In that case, with a properly-configured .pypirc file like the one above in the user's home directory, publishing would be handled something like this:

To publish to pypi (the default), enter:

uv publish

To publish to test.pypi, enter:

uv publish -r testpypi

Private repos/others look like this:

uv publish -r private-repository

[zanieb]

I guess we probably should since it's a standardized file though it seems a bit behind-the-times as there are several warnings suggesting alternative methods for authentication. It's also weird that it has a [distutils] section. We're generally very hesitant to read from other tool's configuration i.e. #1404

[geozeke]

Fair points. Definitely an only-if-it-makes-sense feature request 😊

[zanieb]

I'm actually not sure this is a standard it might just be recommended by the PyPA? I'll follow up on that.

Added to the guide in pypa/packaging.python.org#734 and it looks like twine just used distutils to parse it originally per pypa/twine#15

There's an open pull request from 2017 that updates the guide to discourage use of pypirc? pypa/packaging.python.org#297

[geozeke]

Thanks for the link. Interesting conversation in the PR from 2017. Some talk of keyring support being a little "flaky" on linux [at that time], so maybe .pypirc use was kept around. Much has changed since then, so maybe its use is considered legacy at this point.

[raayu83]

I think support for .pypirc would still be useful.
There are people who work in environments where .pypirc is set up automatically in the CI/CD environment and changing that to support new authentication methods would take some time and need to be prioritized first.
Therefore I believe supporting .pypirc would help increase adoption of uv.

[bulletmark]

I created a wrapper for this: https://github.com/bulletmark/uv-publish.

[cthoyt]

Big agree on this! My workflow uses twine upload --skip-existing dist/* locally and relies on the .pypirc file. I'm very excited to replace this with uv publish if it doesn't require me having to reengineer my local environment.

The other benefit of the config file is it lets you keep track of multiple index’s credentials

(yes, I know that everyone is moving over to using trusted publishing, but I'm not ready for that yet)

[spapanik]

My 2p: The .pypirc is extremely annoying that uses the distutils name, and the format is outdated, as [pypi] doesn't even accept a username anymore. But copying and pasting the token is not great, and also having tokens in env vars is not generally recommended (for example the Postgres documentation has this about the PGPASSWORD variable: PGPASSWORD behaves the same as the password connection parameter. Use of this environment variable is not recommended for security reasons, as some operating systems allow non-root users to see process environment variables via ps; instead consider using a password file)