Re: bug#58985: 29.0.50; Have auth-source-pass behave more like other back ends

[J.P.]

Akib Azmain Turja <akib@disroot.org> writes:

>>> I suggest to prefer the "@" syntax over "/user" syntax.
>>
>> I have tried tweaking things in that direction. But as far as
>> deprecating the /user form officially: that seems more like a group
>> decision. And then there's the question of how to express such a policy.
>> Should we emit a warning? At the very least, it would need to be
>> documented somewhere.
>
> No, I didn't say to deprecate that syntax, the syntax makes much sense.

Oh, well then pardon my inferring that. But without deprecation, we'd
need to somehow "encode" the @-wins behavior into the interface with
documentation and tests, which is usually more complex than it first
appears. Otherwise, we can just treat @ favoritism as an implementation
detail not subject to preservation come some future rewrite or major
overhaul. As things stand, this patch mostly takes the latter approach
(tests aside).

> I'm suggesting to return "USER@HOST" if both "USER@HOST" and "HOST/USER"
> are present, because the former makes more sense.

Right, I guess you didn't bother trying out the latest changes attached
to my previous email, which is fine. The thing I'd like to stress here
(mainly for posterity) is that the degree to which we demote/defer
candidates of the / form is deliberate. The way I have things now gives
search order primacy over @-vs-/ contention, meaning a search tree like

        h           g
     /     @     /     @
    1 2   1 2   1 2   1 2

and params like

  :host '("h" "g") :port 2 :max 5

gives

  @h:2, h:2/, @g:2, g:2/

whereas full demotion (not implemented) would yield

  @h:2, @g:2, h:2/, g:2/

IOW, if you omit the :port 2 part, you currently get

  @h:1, @h:2, h:1/, h:2/, @g:1

which is likewise expected.

Basically, the current search strategy adheres more closely to how the
other back ends operate and is thus preferred.

>> Anyway, this is useful analysis. Thanks again for all your help.
>
> When are you going to install this?  It's definitely an improvement over
> the one in master, and doesn't have any problems to block it.
> Installing it will also expose it to more users to the change, so this
> will get even more testing.

I am willing to install this but am not really comfortable enabling it
by default unless the maintainers of the downstream packages (Cc. Björn)
can promise to report any problems while Emacs 29.1 is still unreleased.
Without such a pledge, I'm inclined to just leave it disabled. Thanks.