https://bitbucket.org/kang/python-keyring-lib/wiki/Redesign
Let me know what you think about it, or if anything is unclear.
Cheers!
--
Alan Franzoni
--
contact me at public@[mysurname].eu
Ping! Thoughts?
Hey,
So, this part is unclear to me:
"Would take as input the list of all working keyring on the current
platform, and should return the best suited keyring"
How it does perform this ? If I have several backends available, how
does it pick one ?
>
> --
> Alan Franzoni
> --
> contact me at public@[mysurname].eu
>
--
Tarek Ziadé | http://ziade.org
KeyringPickStrategy is just a description of our strategy interface, I
just wanted to make it clear what's its signature. Since it's a
strategy, *how* it does pick one depends on how it's implemented.
the DefaultKeyringPickStrategy is our *default implementation* of
KeyringPickStrategy, and should act as described.
I realize the part regarding the DefaultKeyringPickStrategy maybe
wasn't so clear, I've just tidied it up a bit.
It says:
if there's no configured keyring, guess depending on platform,
available keyrings, ecc. and return it.
So how the guess works ? Because that's how it will differ from what
we have today.
Can you take the backends we provide and explain how you pick one and
depending on what ?
>
>
> --
> Alan Franzoni
> --
> contact me at public@[mysurname].eu
>
--
Tarek Ziadé | http://ziade.org
I'm afraid I don't have much time to contribute. Improvements are of
course a good thing. My one thought/request would be that backward
compatibility with the existing APIs (which is, hopefully, defined by
the test suite) be preserved.
If backward compatibility can't be preserved then perhaps a new package
name is in order so users of the existing package won't be affected.
--
Benji York
That's an implementation detail. I think it's not that important by
itself; what it's really important is that the strategy can be
injected into the get_configured_keyring call. This allows any client
code to pick a different strategy.
By the way, in our default strategy I'd probably try to do something like:
- check if anything was configured in keyring.cfg; if a backend was
configured and it's available, return it. If it isn't, throw an error
(maybe) ?
- check which os we're running, and try choosing the best os-aware
keyring; try not to rely on unpredictable things, e.g. if the input is
the same and the environment is the same, then the output should stay
the same.
- if the os-aware functions don't return a "most suitable" keyring,
pick the first one, always trying to stay consistent throughout
function calls.
But I'm open for discussion on such theme. I don't have The Answer
I agree on the fact that, if backwards compatibility is impossible to
achieve, and since dependency management seems pretty hard to do with
Python at this time, a whole new project (keyring2?) should be
started; are there any more opinions on the redesign proposal by
itself?