Add two new optional configuration locations to consider.

[goodtune]

While earlier Python package uploading tooling only looked only for ~/.pypirc file there is no need to stick to this convention forever.

This patch introduces a secondary user level configuration path, namespaced to this tool, and also a system-wide location that allows system administrators to provide a sensible default.

This implementation uses the appdirs project to handle the cross platform decision making for us (initial use case is to provide a Windows user experience managed across a fleet of workstations equally
to Linux development environments).

Linux precedence for jsmith:

• /home/jsmith/.config/twine/.pypirc
• /home/jsmith/.pypirc
• /etc/xdg/twine/.pypirc

Windows precedence for jsmith:

• c:\Users\jsmith\AppData\Local\twine\.pypirc
• c:\Users\jsmith\AppData\Roaming\twine\.pypirc
• c:\Users\jsmith\.pypirc
• c:\ProgramData\twine\.pypirc

This does not attempt to teach twine to overload a lower precedence configuration with a higher one.

Refs #349.

[sigmavirus24]

Multiple configuration file locations and how to handle "merging" them is the bane of every single project's existence.

The established convention is ~/.pypirc. We could evolve, certainly, but I don't think we should ever use config files that are global to a computer, and I'm not sure we want to support both ~/.pypirc and XDG. Flake8 has tried to support all of the above and it has been an absolute nightmare.

[goodtune]

Note that I'm not proposing merging of configuration - simply a precedence contract.

I would argue that it's pretty compelling to be able to configure something in one place for all users of a system. For the same reason we install one copy of twine to the host to be shared by all user it makes sense to configure their upstream repositories so things Just Work out of the box - no need to install and configure the tool in whatever user space you happen to be working in.

I can understand that it may add a little more effort to debug (which config got loaded?) but I think it is well worth it when you consider the impact of having hundreds of users who all need to write to C:\Users\username\.pypirc to be able to use the tool instead of 1 installation task that writes to C:\ProgramData\twine\.pypirc.

If this is handled for the user then the need to maintain a personal ~/.pypirc is so diminished that you should expect that the existence of ~/.pypirc is an anomaly to be eliminated except in some edge cases.

Would adding the default file to be used in the --help output assist?

This is backwards compatible - the retention of ~/.pypirc with higher precedence than a system default ensures any existing configuration would continue to be honoured if an administrator opted to deploy a system default.

[jaraco]

I'm in support of this change in principle - I'd like for config files to be placed at the scope where they're most meaningful, which this change attempts to do.

Where I think this proposal is misguided, however, is in treating .pypirc as a twine-only resource, when in practice, it's used by a number of tools, including distutils, setuptools, and maybe others. What is the user-story for someone using more than just twine?

I'm glad to see it's using appdirs - that's an excellent re-use of commodity behavior.

I think this project could accept this change if it's obvious that twine should own this file or that twine's usage of that file is known (and documented) to be more broad than that of other programs.

Perhaps better would be to expose this functionality as a library that any tool could use to locate and load a .pypirc (although that sounds like a pretty substantial challenge in itself).

I'm open to ideas here, but I'm somewhat reluctant to accept it without at least some consideration about the above concerns.

[di]

I agree with @jaraco that we should not consider this a twine-only configuration file, and change our behavior here without changing how this should work in other similar tools.

I do support this in theory though. I think if we want to actually make this change, the right way to do it would be to include some standardization of the .pypirc file in the PEP which defines the PyPI upload API. (cc @brainwane, are you still working on this?).

Given that (and the age of this PR) I'm going to close this, but thanks for the contribution.

(Also, in the future, I'd encourage you to open an issue first to capture relevant discussion before making a PR, to save you from doing unnecessary work!)

[di]

Oops, really sorry -- just noticed that you did indeed create an issue (#349), thanks for that. In that case I'd advise you to wait for some discussion next time 🙂

[brainwane]

include some standardization of the `.pypirc` file in the PEP which defines the PyPI upload API. (cc @brainwane <https://github.com/brainwane>, are you still working on this?).

Thank you for asking. I am not. If you could update pypa/packaging-problems#128 accordingly while I am busy with family stuff (the next few weeks) I would appreciate it so someone else has a chance to pick it up.