Setuptools: Allow environment variable override of .pypirc

[srikanth-viswanathan]

When setuptools is run in a CI environment such as Jenkins, it is desirable to place the .pypirc file in the local directory of each job rather than the global location ~/.pypirc. Please allow users to override the default location via an environment variable such as PYPI_CONFIG_FILE. Happy to provide PR if we agree that this is a feature worth having.

[jaraco]

The .pypirc file applies to more than just setuptools. It's used by distutils and twine and probably others.

But more importantly, the purpose and location of the file is defined in Python itself, and the purpose is meant to be cross-project and to store settings that are associated with the user and not the project.

So before we go adding new interfaces to tweak how one might use this file, I'd rather explore what use-case you have that's leading you to the need to have a .pypirc at all. For example, setuptools itself runs its tests in Travis-CI, so not Jenkins, but it does incorporate automated deployments all without the use of .pypirc.

In my organization, we do use Jenkins, and there we don't do automated deployments, but our manual deployments also don't rely on .pypirc. Instead, they simply indicate the index url in their upload command in setup.cfg:

[upload]
repository = https://devpi.example.com/root/repo/

Then, each user may have a .pypirc which indicates the username for that repo (and Jenkins could have a username which is relevant to its uploads):

[distutils]
index-servers =
    pypi
    myco

[pypi]
repository: https://upload.pypi.org/legacy/
username: jaraco

[myco]
repository: https://devpi.example.com/root/repo/
username: jaraco

Would an approach like this work for your use-case?

[srikanth-viswanathan]

My situation is that all the jenkins builds runs as the same user. And we would like users to have full control over where they publish, and what credentials they use, within the confines of this jenkins setup. The solution that I thought fit this was to make the location of the .pypirc file overrideable. I entered this (and the PR) hoping this would be a quick fix :-)

That being said, I'm ok if you choose to withdraw this. I didn't realize the purpose of .pypirc was to be a cross-project configuration file. I still feel it could be made overrideable, but I lack the background knowledge to give an informed opinion on that.

[jaraco]

I can see the need for wanting a per-project or per-invocation way to override the settings in .pypirc. Already, there are ways to override the password, and leaving the password in plain text is not desirable anyway. In #941 and #961, I'm exploring a mechanism to allow the username to be inferred from the current user's name and allowing it to be overridden by an environment variable.

A couple of other options that might already be available to you:

Set $HOME such that .pypirc is found elsewhere:

$ HOME=. python -c "import distutils.dist as dist; import distutils.config as cfg; print(cfg.PyPIRCCommand(dist.Distribution())._get_rc_file())"
./.pypirc

That could have undesirable consequences, but perhaps not, especially if isolated to the invocation of upload.

Another alternative is to use the twine package, which allows for the username to be specified on the command-line.

Yes, I think one of these approaches will be better than relaxing a restriction for where .pypirc will be defined in the ecosystem.

Do feel free to continue the conversation if you find none of these approaches will suit your use case.

[fersarr]

@jaraco In our org, there are multiple sub-organizations, and .pypirc contains the password for the sub-organization that the user belongs to. As in multiple companies, home dirs are on a network-shared drive (NFS). For a few months, we have been increasingly using more our kubernetes-backed Jupyterhub world, in which we automatically setup things (mount the NFS home dir, add the .pypirc file, etc.) for the logged-in user automatically. Now if we want to automatically generate these .pypirc files and place them on the home dirs, we need to disable root-squashing on the NFS system to allow us to write as root in the user's home. This obviously is a security issue because that means that anyone using docker could go into a container as root and mount another user's home dir and do whatever they want. If instead, we were able to configure the location of .pypirc to be outside of the NFS directories, we would not have to disable root squashing. We could instead place the files on a location that is not on NFS, only on the user's Kubernetes pod.