Hi Guido!
On Thu, Feb 07, 2008 at 12:41 +0100, Guido Wesdorp wrote:
> Hi!
>
> Someone asked me if I want to implement support for passing a username
> and password to the py.path.svn* functionality, allowing the application
> to provide a username and pw both for svnurls and svnwcs. I've
> investigated SVN and the code a bit, and it looks like this can be done
> in a relatively nice way:
>
> * svn seems to support command-line arguments for username and password,
> and also for telling it to not store auth information - with these
> arguments we can make sure the username/pw we provide are used, and not
> stored on the client
why do you want to make sure this is not stored on the fs?
> * there's a switch --non-interactive which we can then enable to make
> very sure applications don't hang on asking username/password or things
> like that (currently that can be a problem when using svnwc or svnurl in
> scripts)
Sometimes py.path.svn* objects are used in interactively running
scripts in which case it's ok that they ask for input.
> I guess this would mean that for all operations that hit the server, the
> username and password arguments should be added. Perhaps it would be
> nice to have to provide it only on instantiation or something, although
> I fear that that will be harder to implement and use correctly in the
> situation of nested working copies (externals), etc.
Not sure about externals but i guess it's possible to allow for roughly
this to work:
wc = py.path.svnwc("somepath")
wc.checkout(URI, username=xxx, password=yyy)
for subwcpath in wc.listdir():
assert subwcpath.username # inherited auth information
assert subwcpath.password
...
However,
1) inheriting auth information may not always be what one wants
2) it's simpler to rely on the client FS storing auth data
> I hope you guys like the idea of having this in the py lib, it sounds
> like a useful addition to me... If no-one minds, I'll start implementing
> in a couple of days, I'd like to have it done (and tested well,
> obviously) before the release, if possible...
sure - let me note here that due to my prolonged ill-ish-ness (since last
saturday now)
and other surprising developments there may be no full 1.0 in Feb - in this
case i'd suggest to first go for 0.9.1, with just bugfixes and a few added
feaures.
I hope that you and others could help with this.
best,
holger
_______________________________________________
py-dev mailing list
py-dev@codespeak.net
http://codespeak.net/mailman/listinfo/py-dev
