Twine: Suggestion: add an env-var to define --config-file default location/value

[iMoses]

When running in CI, which is a standard use case for twine, it is often considered best practice to use a separate .pypirc file per job meaning that the --config-file cli arg is used a lot.

It would be nice to have an env-var such as TWINE_CONFIG_FILE to set the default for that globally, thus changing the default requirement for .pypirc to be at the home directory.

What says you, yay or nay? :)

[bhrutledge]

This seems reasonable, given the other TWINE_ environment variables already in use. I'd wait for one of the other @pypa/twine-maintainers to sign-off before implementing it.

That said:

it is often considered best practice to use a separate .pypirc file per job

Can you elaborate on this? Do you have links to any docs/discussions that suggest this? What distinguishes the individual files?

[sigmavirus24]

it is often considered best practice to use a separate .pypirc file per job

I've been working on F/OSS Python with CI for close to a decade and I've _never_ heard of this.

I'm also not fond of providing invisible ways of swapping out where someone might be uploading to. CI configuration can be confusing enough that I'd be willing to bet as soon as someone starts using this they'll upload a private, proprietary package to public PyPI and freak out at us for letting them shoot themselves in the foot.

[iMoses]

I've been working on F/OSS Python with CI for close to a decade and I've _never_ heard of this.

Containers are changing quite a lot of practices in recent years as they provide new ways to solve old problems. Having our CI run using Jenkins and the Kubernetes plugin it makes sense for us to have .pypirc in locations other than the home directory, and deployment configurations can change dramatically between different repositories.

I'm also not fond of providing invisible ways of swapping out where someone might be uploading to. CI configuration can be confusing enough that I'd be willing to bet as soon as someone starts using this they'll upload a private, proprietary package to public PyPI and freak out at us for letting them shoot themselves in the foot.

I can understand that and even relate with it.

Perhaps a better suggestion is to have a twine.conf file to contain defaults for twine's CLI args. This way everything will be readable and consolidated in a single file. Maybe it's too big of a feature now, it's just a suggestion, I won't take offence if you decide to pass on it :)

[bhrutledge]

@iMoses Out of curiosity, why aren't the existing environment variables sufficient?

https://twine.readthedocs.io/en/latest/#environment-variables

[iMoses]

@bhrutledge technically they could be enough, as each deployment only requires a single set of username, password and repository. It's just easier and better organized in my opinion when we have all the configuration in a single .pypirc file as use the repository arg instead.

Currently my usage looks something like this:

twine upload dist/* --config-file ${WORK_DIR}/twine/.pypirc -r repo

[bhrutledge]

Possibly related: #349 and #350. The comments there reminded me that .pypirc is not exclusive to Twine, so changes on where it's sourced from should be considered as part of the larger packaging ecosystem. In practice, I think that means it's not going to change in the near future.

Also, a quick scan of tools like pip, tox, and pytest didn't yield an obvious environment variable for setting the configuration file. Rather, they seem to support using environment variables for setting individual configuration options (as Twine does).

With all that in mind, I'm going to close this for now, but if folks feel strongly, we can reopen it.