-
Notifications
You must be signed in to change notification settings - Fork 307
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add precedence based searching for .pypirc when not specified #349
Comments
I closed #350 because while I support us doing this, I think we should make this behavior a standard (possibly in a future PEP which defines the PyPI upload API) before we differ significantly from what other tools do. |
Possibly worth considering #230 as part of this work. |
Speaking as someone who has maintained Flake8 for years which has a convoluted precendence based search for configuration files, this is never intuitive to all users and often works contrary to at least half of what users want. 1 config file, is all I will ever support us using. Multiple files with precedence based merging only ever leads to confusion, frustration, and years off of both user and maintainer lives |
I would gladly gather around an open fire and hear what stories might that bring 😃
All of that is true, but there are multiple projects, multiple minds, and some people "just" want this or that. 😕 Leaks (security or otherwise) are inevitable for one-global-file configs. I only ever heard of Black achieving zeroconf, and I haven't still opened up that Pandora's box. |
I don't understand your statement here.
Please provide your threat assessment that leads to a leak from
Black allows for configuration but has strictly limited it to 1 file that's local to the project, as a tool like Black should do. |
I get why inherited configuration in a project such as Flake is complicated. Different users want different configuration, and different projects want different configuration. (That's more of an observation)
It sounds more secure to create project-only API keys. I think pypi itself tries to make you do so. If that would happen, they could move together with the repository directory wherever I might need that directory to appear in. At this time, my only easy option appears to be: I have indeed only recently touched
I meant zeroconf as in "most likely, you don't need to touch the defaults". Therefore, there is less need to create opinionated configuration, and therefore move configuration around (which is what merge/inheritance wants to solve IMU). |
#496 is the discussion towards making it easy to use per-project tokens. But your only option isn't to store your account-wide API key there. You don't have to store any credentials and can provide then upon upload. It's not a great or easy user-experience, but it's secure. Until we've hammered out the right way to do per-project tokens, and if you're actually severely concerned about the security of that file, I suggest you take the path of storing the tokens somewhere you trust. This has been my own tact for storing my PyPI password for several years now |
I would like to dream so 😛 It seems, all it did to solve a python3.3 old issue (pypa/packaging.python.org#730) was to simply nudge. So, I thought of nudging here too 😃 |
I don't understand this or the rest of your comment or its relevance to the discussion of multiple pypirc files. Besides, you also haven't provided a threat model where a user's pypirc file could be leaked but not another pypirc owned by the same user in a sub-directory couldn't. |
Another use case: Currently we use the It would be great for twine to either:
|
Based on the discussion here and at #830 (comment), I think it's unlikely that Twine will support the additional request. I believe that the use cases described here can be addressed by using That said, if folks have still specific pain points they're trying to address, I recommend opening a new issue that describes the problem, and then we can discuss possible solutions. |
Taking a lead from
pip
which will look forpip.conf
orpip.ini
in several locations, I suggest thattwine
follow a similar pattern.I have recently been undertaking work to improve the user experience for developers who need to interact with our internal
pypi
repository and while it was trivial to provide them with a sensible configuration to consume packages from the index, the same could not be said of making it easy to publish.The text was updated successfully, but these errors were encountered: