Reading credentials from .pypirc

[funkyfuture]

this is an approach to solve #561.

another way could be to wrap it all up in one credentials object that contains all the logic, including the cache updates.

therefore i'd appreciate feedback in this regard.

[ofek]

Any desire to rebase and pick this back up?

[funkyfuture]

yes, likely within some weeks.

looking at the proposal again, personally i'd really prefer a complete Authentication class, i put some comments in where that'd matter. please let me know what you prefer.

[funkyfuture]

okay, i rebased and completed the feature.

[funkyfuture]

@ofek i don't know the interfaces here good enough, excuse me if this is redundant: i amended changes and the CI needs to be kicked off again.

[funkyfuture]

@ofek i rebased again. can you kick off the checks again? force-pushing seems to not play along well in the system.

[funkyfuture]

happy new year @ofek, i'd appreciate a feedback here.

[ofek]

Happy new year to you as well! I plan to include this in the next minor release it's just that there are a lot of changes here so it takes up a lot more time to review.

Would you be willing to refactor a bit less so I can review this faster? If not it's okay and I just have to schedule extra free time

[funkyfuture]

Would you be willing to refactor a bit less so I can review this faster?

not really without specific suggestions. and i also think that the refactoring is worth it as it consolidates how the different credentials sources are considered (i could argue that this is overdue and thus should be prioritized over new features) and thus should allow easier extensions in the future.

[funkyfuture]

thanks for the valuable feedback.

[ofek]

Note this resolves #1191

[ofek]

Almost done, thanks!

[funkyfuture]

a'ight then.

[ofek]

Thank you very much for your efforts and your patience!

[lfvjimisola]

From what version of hatch is this expected to be available?

[ofek]

The next minor release.

[albertas]

I see that hatch 1.9.4 version was released last week, but this feature was not yet included. Should we expect it to ship in 1.9.5?

[ofek]

This project uses semantic versioning so features only happen in minor releases e.g. 1.10.0

[vaab]

I'm using last master, checked to have the commit f59508b, and actually am using pdb inside publish/auth.py to try to figure why the default file coming from the pypi 2FA token generation page is not accepted and read as-is.

It seems it looks for a main section, and not pypi, then looks in all sections and looks for a repository option to match with https://upload.pypi.org/legacy/. Neither of these strategy will succeed with the format proposed by pypi itself when asking for a non-specific all power token, which is:

[pypi]
  username = __token__
  password = xxxx

(Don't worry for this token, as it was deleted before publishing it here)

Did I miss something obvious, or is that made on purpose ? If yes, may I ask the rationale (or a pointer to it) ?
Workarounds are obvious for me, knowing the code, but this might raise questions from other users also.

[funkyfuture]

@vaab not sure whether i'm missing something from your description, but it seems that the behaviour that you expect is tested in the commit you reference. please verify that this is the case.

[vaab]

Sorry if I was not clear. I guess you are referring to this test.

However, the AuthenticationCredentials class in the test is instantiated in a specific way (setting repo as the empty string, which will get then defaulted to 'pypi' in this logic, and, as a consequence, will work). However that doesn't seem to reflect how it is instantiated in a normal run, where the repository name is defaulted to 'main' (instead of empty string) prior to the instantiation (cf: here)

In my case, with a very default/simple installation, without customization, the first part of the logic looks for a main section (and fails to find it), then switch to the second part of the logic, looking for every sections that would have a repository option matching a precise url (with ending slash). Without a context, the pertinence of this last equality check is difficult to grasp and all this seems brittle.

And this explains why the test works, and a real world example fails. I believe my setup is a very default setup, and its quite clear why it fails, and it comes from this default 'main' section lookup, and these 2 different logic. The test should test on 'main' string and not empty string if it wants to reflect what I feel is normal usage. I'm obviously missing a lot of context, so I'm sorry if there are obvious things I missed.

The workaround for me was to add an option repository in the pypi section:

[pypi]
  username = __token__
  password = xxxx
  repository = https://upload.pypi.org/legacy/

But this won't be expected by most user I guess (and the URL should be exactly matched, with leading /).

[vaab]

As I have good reasons to think that this will be reported as an issue soon, should I open a bug request and or propose a PR to solve this ? I didn't get any perspective on this point. Many thanks for any feedback.

[ofek]

Yes please!

[funkyfuture]

If you provide a PR with a reproducing test, I'll take it from there.

[manmartgarc]

Is there a way to pass an option to hatch publish to pick a particular item from .pypirc? For example, I'd like to publish to test.pypi and I have an extra entry on my .pypirc flie with the token for the test domain; can I guide hatch publish to use that option?