Skip to content
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

Closed
goodtune opened this issue Apr 24, 2018 · 11 comments
Closed

Add precedence based searching for .pypirc when not specified #349

goodtune opened this issue Apr 24, 2018 · 11 comments
Labels
blocked Issues we can't or shouldn't get to yet feature request

Comments

@goodtune
Copy link

Taking a lead from pip which will look for pip.conf or pip.ini in several locations, I suggest that twine 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.

@di
Copy link
Member

di commented Oct 12, 2019

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.

@bhrutledge
Copy link
Contributor

Possibly worth considering #230 as part of this work.

@sigmavirus24
Copy link
Member

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

@stdedos
Copy link

stdedos commented Jun 4, 2020

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.

I would gladly gather around an open fire and hear what stories might that bring 😃

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

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.

@sigmavirus24
Copy link
Member

All of that is true, but there are multiple projects, multiple minds, and some people "just" want this or that. confused

I don't understand your statement here.

Leaks (security or otherwise) are inevitable for one-global-file configs.

Please provide your threat assessment that leads to a leak from ~/.pypirc versus the project-local pypirc (if one were to exist) and how a precedence-based search mitigates this.

I only ever heard of Black achieving zeroconf, and I haven't still opened up that Pandora's box.

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.

@stdedos
Copy link

stdedos commented Jun 4, 2020

All of that is true, but there are multiple projects, multiple minds, and some people "just" want this or that. confused

I don't understand your statement here.

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)

Leaks (security or otherwise) are inevitable for one-global-file configs.

Please provide your threat assessment that leads to a leak from ~/.pypirc versus the project-local pypirc (if one were to exist) and how a precedence-based search mitigates this.

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:
Store a account-wide API key in ~/.pypirc (or store it securely using keyring)

I have indeed only recently touched twine. If there are better practices out there, maybe it would be a good time to reference those in pypa/packaging.python.org#734

I only ever heard of Black achieving zeroconf, and I haven't still opened up that Pandora's box.

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 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).

@sigmavirus24
Copy link
Member

#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

@stdedos
Copy link

stdedos commented Jun 4, 2020

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.

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 😃

@sigmavirus24
Copy link
Member

I would like to dream so 😛

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.

@5nafu
Copy link

5nafu commented Aug 19, 2020

Another use case:
We use twine to upload packages to a local (authenticated) repository.
I would like to have a developer be able to "just" push changes to that repository without needing to remember /look up the URL.

Currently we use the repository-url option in a Makefile, but this completely ignores any authentication set up in ~/.pypirc, requiring the user to always enter username and password.
Using the -r option, would break if the user has no ~/.pypirc set up (or not using the stated name for the repository). I would use a project wide pypirc file but don't want to have static authentication details in the git repository.

It would be great for twine to either:

  • use well-known filenames in specific locations, merging into each other (like ~/.pypirc, ./.pypirc) or
  • accept multiple --config-fileoptions to specify the files used to configure. (Maybe first one encountered could count?) or
  • check for authentication details in a ~/.pypirc if a --repository-url option is given

@bhrutledge
Copy link
Contributor

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 --config-file and/or environment variables, as well as keyring.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked Issues we can't or shouldn't get to yet feature request
Projects
None yet
Development

No branches or pull requests

6 participants