Redesign proposal

36 views
Skip to first unread message

Alan Franzoni

unread,
Nov 16, 2010, 5:47:38 PM11/16/10
to python-...@googlegroups.com
Here it is:

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

Alan Franzoni

unread,
Nov 24, 2010, 5:28:08 AM11/24/10
to python-...@googlegroups.com
On Tue, Nov 16, 2010 at 11:47 PM, Alan Franzoni <mai...@franzoni.eu> wrote:
> Here it is:
>
> https://bitbucket.org/kang/python-keyring-lib/wiki/Redesign

Ping! Thoughts?

Tarek Ziadé

unread,
Nov 24, 2010, 6:51:02 AM11/24/10
to python-...@googlegroups.com
On Wed, Nov 24, 2010 at 11:28 AM, Alan Franzoni <mai...@franzoni.eu> wrote:
> On Tue, Nov 16, 2010 at 11:47 PM, Alan Franzoni <mai...@franzoni.eu> wrote:
>> Here it is:
>>
>> https://bitbucket.org/kang/python-keyring-lib/wiki/Redesign
>
> 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

Alan Franzoni

unread,
Nov 24, 2010, 7:59:58 AM11/24/10
to python-...@googlegroups.com
On Wed, Nov 24, 2010 at 12:51 PM, Tarek Ziadé <ziade...@gmail.com> wrote:
> 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 ?

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.

Alan Franzoni

unread,
Nov 24, 2010, 8:02:25 AM11/24/10
to python-...@googlegroups.com
On Wed, Nov 24, 2010 at 1:59 PM, Alan Franzoni <mai...@franzoni.eu> wrote:
> 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.

Tarek Ziadé

unread,
Nov 24, 2010, 8:07:52 AM11/24/10
to python-...@googlegroups.com
On Wed, Nov 24, 2010 at 2:02 PM, Alan Franzoni <mai...@franzoni.eu> wrote:
> On Wed, Nov 24, 2010 at 1:59 PM, Alan Franzoni <mai...@franzoni.eu> wrote:
>> 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

Benji York

unread,
Nov 24, 2010, 2:15:15 PM11/24/10
to python-...@googlegroups.com
On Wed, Nov 24, 2010 at 5:28 AM, Alan Franzoni <mai...@franzoni.eu> wrote:
> On Tue, Nov 16, 2010 at 11:47 PM, Alan Franzoni <mai...@franzoni.eu> wrote:
>> Here it is:
>>
>> https://bitbucket.org/kang/python-keyring-lib/wiki/Redesign
>
> Ping! Thoughts?

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

Alan Franzoni

unread,
Nov 27, 2010, 2:40:37 PM11/27/10
to python-...@googlegroups.com
On Wed, Nov 24, 2010 at 2:07 PM, Tarek Ziadé <ziade...@gmail.com> wrote:
> 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 ?

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

Alan Franzoni

unread,
Dec 30, 2010, 12:58:50 PM12/30/10
to python-...@googlegroups.com
Hello,
since I might have some time to work on that in the next few days, I'd
like some more feedback.

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?

Reply all
Reply to author
Forward
0 new messages