[strongSwan-dev] Python vici library
bjorn.schuberg at gmail.com
Fri Mar 6 18:29:45 CET 2015
Nice start on the README. I took a moment to make the python part a bit
more "pythonic", and pushed it to a branch on github:
I've taken a look at your code changes. I definitely agree that implicit
error checking is nicer, and it will make the experience of using the
library much smoother. There is a problem with your implementation of 
however, you are discarding any errors for commands that require event
streaming -- only the events are returned -- there is no way to know
whether the command was successful.
While generators is a good idea for response streaming, it is not a great
fit here. The current implementation works on the assumption that the
generator is exhausted before another command starts. There is no way to
guarantee this, as the user may draw elements from the generator as he/she
wishes. This will make the consecutive command fail in best case, and in
the worst case, return the wrong result. Another problem is that no errors
are reported due to .
Here is an example:
>>> import vici
>>> s = vici.Session()
>>> g = s.list_certs()
>>> msg = next(g)
>>> print s.version()
Traceback (most recent call last):
File "scr.py", line 6, in <module>
File "vici/session.py", line 21, in version
File "vici/session.py", line 238, in request
vici.exception.SessionException: Unexpected response type 7, expected '1'
For this to be implemented properly, the way the library currently send and
receive messages must be rethought.
2015-03-02 15:45 GMT+01:00 Martin Willi <martin at strongswan.org>:
> > Your README.rst is not yet part of it, probably we should integrate
> > that to the vici README.md.
> I've updated our vici README.md  to include some basic steps to get
> started with the python library.
> In addition, I'd like to propose a minor change to the main Session
> command calls. Instead of returning a CommandResult, I'd prefer to raise
> a CommandException if a command failed .
> While I think implicit error checking with exceptions makes sense, the
> main reason for that change is that it allows us to return generators
> for streamed objects . I think that is favorable, especially as some
> longer lasting commands return immediate feedback when called
> interactively. For example, the initiate() command directly returns
> streamed log messages, long before the command finally succeeds or
> Please let me know what you think about these changes.
> Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dev