tg2 adapter
54 views
Skip to first unread message
Alex Bodnaru
Feb 27, 2014, 1:36:19 PM2/27/14
to pytho...@googlegroups.com
hello friends,
as i wanted to add web services to our website, tgwebservices was missing for me in tg 2.
luckily, before trying to port it, wsme popped in my search, so i ported an active project made for portability.
my port is based on tg1*, but departs in functionality where needed or made sense.
attached are my files with brief explanation on how to integrate.
i have slightly modified the client in order to print the commands before they run.
the demo was slightly modified, so that it is made with stock wsme, not with the adapted commands. thus, the same demo may be imported in various modules, with different adapters.
thank you very much for providing wsme, and please consider my modest contribution.
alex
Christophe de Vienne
Feb 28, 2014, 4:23:53 AM2/28/14
to pytho...@googlegroups.com
Hello Alex,
Thank you for contribution !
Funnily enough, I originally wrote wsme because porting tgwebservices to
tg2 meant an almost complete rewrite and I did not want to maintain 2
codebases... and in the end I never implemented the tg2 adapter !
Concerning your patch, I cannot include it as is for several reasons.
The main reason is that I don't think it works properly (although I
haven't test it completely).
The thing is that the demo you provide actually use the standalone wsme
WSRoot and its associated decorators, and not the decorators from your
adapter.
Also, your scan_api function takes a WSRoot as its root controller,
where it whould have been the root controller of your application (a TG2
one).
To clarify a bit what I say, let me precise that the goal of the
adapters is to expose functions inside the hosting framework controllers
directly instead of having to use a WSRoot controller. Hence, you can
rely on your framework routing capabilities, which are most of the time
greater than the basic wsme WSRoot controller [1].
So I suggest you have a closer look at the existing adapters and their
unittests in the latest wsme version.
Also, to make you patch complete, you should add some unittests (see the
'test' directory and tox(-tmpl).ini). Do not hesitate to ask for help
for writing them if you need.
Adding some documentation would be good too.
Last thing, to ease the review and merge of the patch, the preferred way
is to push it to gerrit instead of sending a tarball. See
https://wiki.openstack.org/wiki/Gerrit_Workflow for detailled
explanations (don't mind the licensing issues in 'Account Setup' : wsme
is hosted by openstack but is not an openstack project).
Cheers,
Christophe
[1]
https://wsme.readthedocs.org/en/latest/integrate.html#general-considerations
> --
> You received this message because you are subscribed to the Google
> Groups "python-wsme" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to python-wsme...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
Thank you for contribution !
Funnily enough, I originally wrote wsme because porting tgwebservices to
tg2 meant an almost complete rewrite and I did not want to maintain 2
codebases... and in the end I never implemented the tg2 adapter !
Concerning your patch, I cannot include it as is for several reasons.
The main reason is that I don't think it works properly (although I
haven't test it completely).
The thing is that the demo you provide actually use the standalone wsme
WSRoot and its associated decorators, and not the decorators from your
adapter.
Also, your scan_api function takes a WSRoot as its root controller,
where it whould have been the root controller of your application (a TG2
one).
To clarify a bit what I say, let me precise that the goal of the
adapters is to expose functions inside the hosting framework controllers
directly instead of having to use a WSRoot controller. Hence, you can
rely on your framework routing capabilities, which are most of the time
greater than the basic wsme WSRoot controller [1].
So I suggest you have a closer look at the existing adapters and their
unittests in the latest wsme version.
Also, to make you patch complete, you should add some unittests (see the
'test' directory and tox(-tmpl).ini). Do not hesitate to ask for help
for writing them if you need.
Adding some documentation would be good too.
Last thing, to ease the review and merge of the patch, the preferred way
is to push it to gerrit instead of sending a tarball. See
https://wiki.openstack.org/wiki/Gerrit_Workflow for detailled
explanations (don't mind the licensing issues in 'Account Setup' : wsme
is hosted by openstack but is not an openstack project).
Cheers,
Christophe
[1]
https://wsme.readthedocs.org/en/latest/integrate.html#general-considerations
> You received this message because you are subscribed to the Google
> Groups "python-wsme" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to python-wsme...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
Alex Bodnaru
Mar 1, 2014, 10:36:32 AM3/1/14
to pytho...@googlegroups.com
hello christophe,
thanks for your rapid consideration.
let me reply inline:
On Friday, February 28, 2014 11:23:53 AM UTC+2, Christophe de Vienne wrote:
The main reason is that I don't think it works properly (although I
haven't test it completely).
well, i'd be glad to help or test anything would be needed.
The thing is that the demo you provide actually use the standalone wsme
WSRoot and its associated decorators, and not the decorators from your
adapter.
the demo is your demo. i have purposely taken a situation not depending on my code.
but now i'm also attaching a new controller, inheriting from wsroot and tgcontroller, that performs the same in native tg2.
so, any wsroot controller can be used directly.
please see my attachment.
but now i'm also attaching a new controller, inheriting from wsroot and tgcontroller, that performs the same in native tg2.
so, any wsroot controller can be used directly.
please see my attachment.
Also, your scan_api function takes a WSRoot as its root controller,
where it whould have been the root controller of your application (a TG2
one).
no, you're wrong here.
if you call scan_api() with no controller, the root of my app is being taken. that invoked by index.
all controllers in my solution inherit from tgcontroller, including the wsme wrapping wsgicontroller.
in the scanning process, wsexposed methods of tgcontroller would be yield. these specialized for tg2.
but if a wsme wrapping wsgicontroller would be encountered, the scan would be delegated to it.
thus, all exposed methods, either specific to tg2 or not, would be yield correctly.
i have specifically tried this by the demo in my comment.
besides that demo, some wsexposed entries have been put throughout my controller tree.
well, i hope now that's better.
if there's a backend specific test, please let me know.
best regards,
alex
if you call scan_api() with no controller, the root of my app is being taken. that invoked by index.
all controllers in my solution inherit from tgcontroller, including the wsme wrapping wsgicontroller.
in the scanning process, wsexposed methods of tgcontroller would be yield. these specialized for tg2.
but if a wsme wrapping wsgicontroller would be encountered, the scan would be delegated to it.
thus, all exposed methods, either specific to tg2 or not, would be yield correctly.
i have specifically tried this by the demo in my comment.
besides that demo, some wsexposed entries have been put throughout my controller tree.
well, i hope now that's better.
if there's a backend specific test, please let me know.
best regards,
alex
Christophe de Vienne
Mar 9, 2014, 4:26:50 PM3/9/14
to pytho...@googlegroups.com
Hello Alex,
Le 01/03/2014 16:36, Alex Bodnaru a écrit :
hello christophe,
thanks for your rapid consideration.
let me reply inline:
On Friday, February 28, 2014 11:23:53 AM UTC+2, Christophe de Vienne wrote:The main reason is that I don't think it works properly (although I
haven't test it completely).
well, i'd be glad to help or test anything would be needed.
The thing is that the demo you provide actually use the standalone wsme
WSRoot and its associated decorators, and not the decorators from your
adapter.
the demo is your demo. i have purposely taken a situation not depending on my code.
Well, my demo is not relevant at all when embedded in another
framework with an adapter.
but now i'm also attaching a new controller, inheriting from wsroot and tgcontroller, that performs the same in native tg2.
so, any wsroot controller can be used directly.
please see my attachment.
Also, your scan_api function takes a WSRoot as its root controller,
where it whould have been the root controller of your application (a TG2
one).
no, you're wrong here.
if you call scan_api() with no controller, the root of my app is being taken. that invoked by index.
all controllers in my solution inherit from tgcontroller, including the wsme wrapping wsgicontroller.
in the scanning process, wsexposed methods of tgcontroller would be yield. these specialized for tg2.
but if a wsme wrapping wsgicontroller would be encountered, the scan would be delegated to it.
thus, all exposed methods, either specific to tg2 or not, would be yield correctly.
i have specifically tried this by the demo in my comment.
besides that demo, some wsexposed entries have been put throughout my controller tree.
Well, I was confused by line 214, which clearly feeds a
sub-controller to the scan_api function. I don't think this function
is meant to work this way.
Another thing that is confusing is the way you combine TGController and WSRoot.
This is clearly not needed.
The idea is that unless you want to enable additionnal protocols, you do not need a WSRoot. Only exposing functions with the decorators provided by the adapter is enough.
The scan_api function allows a WSRoot that would be 'mounted' on, say, '/ws', to handle additionnal protocols and still call functions that are not in its own sub-paths.
This make your example (in the module docstrings) incorrect.
A typical TG2 application would not need to "addprotocol" for restjson and restxml, only for soap _if_ additional protocoles are needed only.
Concerning the registration of the renderers, I suggest the adapter provides a function that takes a "config" object as argument and does the job itself.
This way, the environment would only need 2 lines :
import wsmeext.tg2
wsmeext.tg2.setup(base_config)
Still about the renderers, the "mod" parameter and the way you pass it seems odd.
In the exception handler, why is there a try..finally? Do you really expect some exception to occur at this point? And does exception_info really need to be deleted?
About the unittests I need, take a look at the pecan and the TG1 unittests that are in the "test" directory. The basic idea is to set up a test application with unittests inside it. Tox will run them as part of the whole test suite.
Also, note that the adapter should live in "wsmeext/tg2.py".
Is there any reason why you did not use gerrit to submit your patch ? Doing so would make the reviewing process way easier.
Best regards,
Christophe
Another thing that is confusing is the way you combine TGController and WSRoot.
This is clearly not needed.
The idea is that unless you want to enable additionnal protocols, you do not need a WSRoot. Only exposing functions with the decorators provided by the adapter is enough.
The scan_api function allows a WSRoot that would be 'mounted' on, say, '/ws', to handle additionnal protocols and still call functions that are not in its own sub-paths.
This make your example (in the module docstrings) incorrect.
A typical TG2 application would not need to "addprotocol" for restjson and restxml, only for soap _if_ additional protocoles are needed only.
Concerning the registration of the renderers, I suggest the adapter provides a function that takes a "config" object as argument and does the job itself.
This way, the environment would only need 2 lines :
import wsmeext.tg2
wsmeext.tg2.setup(base_config)
Still about the renderers, the "mod" parameter and the way you pass it seems odd.
In the exception handler, why is there a try..finally? Do you really expect some exception to occur at this point? And does exception_info really need to be deleted?
About the unittests I need, take a look at the pecan and the TG1 unittests that are in the "test" directory. The basic idea is to set up a test application with unittests inside it. Tox will run them as part of the whole test suite.
Also, note that the adapter should live in "wsmeext/tg2.py".
Is there any reason why you did not use gerrit to submit your patch ? Doing so would make the reviewing process way easier.
Best regards,
Christophe
Alex Bodnaru
Mar 11, 2014, 11:48:23 AM3/11/14
to pytho...@googlegroups.com
hello christophe,
On Sunday, March 9, 2014 10:26:50 PM UTC+2, Christophe de Vienne wrote:
Hello Alex,
Le 01/03/2014 16:36, Alex Bodnaru a écrit :
Well, my demo is not relevant at all when embedded in another framework with an adapter.
hello christophe,
thanks for your rapid consideration.
let me reply inline:
On Friday, February 28, 2014 11:23:53 AM UTC+2, Christophe de Vienne wrote:The main reason is that I don't think it works properly (although I
haven't test it completely).
well, i'd be glad to help or test anything would be needed.
The thing is that the demo you provide actually use the standalone wsme
WSRoot and its associated decorators, and not the decorators from your
adapter.
the demo is your demo. i have purposely taken a situation not depending on my code.
i'll confess i took your demo since i had no web service of myself.
but in the _tg2 demo i have implemented the same using @ws.. decorators.
both demos will work together, and would be scanned by my scan_api:
mine since has TGControllers with @ws .. methods, and yours since it's incorporated in an WSController.
but in the _tg2 demo i have implemented the same using @ws.. decorators.
both demos will work together, and would be scanned by my scan_api:
mine since has TGControllers with @ws .. methods, and yours since it's incorporated in an WSController.
but now i'm also attaching a new controller, inheriting from wsroot and tgcontroller, that performs the same in native tg2.
so, any wsroot controller can be used directly.
please see my attachment.
Also, your scan_api function takes a WSRoot as its root controller,
where it whould have been the root controller of your application (a TG2
one).
no, you're wrong here.
if you call scan_api() with no controller, the root of my app is being taken. that invoked by index.
all controllers in my solution inherit from tgcontroller, including the wsme wrapping wsgicontroller.
in the scanning process, wsexposed methods of tgcontroller would be yield. these specialized for tg2.
but if a wsme wrapping wsgicontroller would be encountered, the scan would be delegated to it.
thus, all exposed methods, either specific to tg2 or not, would be yield correctly.
i have specifically tried this by the demo in my comment.
besides that demo, some wsexposed entries have been put throughout my controller tree.
Well, I was confused by line 214, which clearly feeds a sub-controller to the scan_api function. I don't think this function is meant to work this way.
WSController is the wsmeext.tg1 adapted controller, that gets a wsroot controller, like your demo.
Another thing that is confusing is the way you combine TGController and WSRoot.
This is clearly not needed.
The idea is that unless you want to enable additionnal protocols, you do not need a WSRoot. Only exposing functions with the decorators provided by the adapter is enough.
indeed. i've followed your demo again.
The scan_api function allows a WSRoot that would be 'mounted' on, say, '/ws', to handle additionnal protocols and still call functions that are not in its own sub-paths.
my scan_api would, by default, scan from the application root.
you should know better, but i doubt whether /ws/api.wsdl should expose a service at /another_service.
my feeling is, that /ws/api.wsdl should scan from /ws, but i trust your code to expose only what's needed.
anyway, what are you trying exactly and fails?
you should know better, but i doubt whether /ws/api.wsdl should expose a service at /another_service.
my feeling is, that /ws/api.wsdl should scan from /ws, but i trust your code to expose only what's needed.
anyway, what are you trying exactly and fails?
This make your example (in the module docstrings) incorrect.
A typical TG2 application would not need to "addprotocol" for restjson and restxml, only for soap _if_ additional protocoles are needed only.
absolutely. i've just followed your demo here. only soap seems to need addprotocol, indeed.
Concerning the registration of the renderers, I suggest the adapter provides a function that takes a "config" object as argument and does the job itself.
This way, the environment would only need 2 lines :
import wsmeext.tg2
wsmeext.tg2.setup(base_config)
i wanted them short, but only to remove redundancy.
what you suggest here, is to also override addprotocol and further depart from the original. possible.
what you suggest here, is to also override addprotocol and further depart from the original. possible.
Still about the renderers, the "mod" parameter and the way you pass it seems odd.
it's a poor man's envelopping ;). a free rider in the params dict.
In the exception handler, why is there a try..finally? Do you really expect some exception to occur at this point? And does exception_info really need to be deleted?
this is an untouched fragment of wsmeext.tg1. didn't think of it too much.
About the unittests I need, take a look at the pecan and the TG1 unittests that are in the "test" directory. The basic idea is to set up a test application with unittests inside it. Tox will run them as part of the whole test suite.
please send me an example of what to test and how.
Also, note that the adapter should live in "wsmeext/tg2.py".
anywhere. i keep it outsider for the moment, to prevent losing it with your upgrades.
Is there any reason why you did not use gerrit to submit your patch ? Doing so would make the reviewing process way easier.
i think i'll need initiation to use gerrit.
Best regards,
Christophe
thank a lot,
alex
Alex Bodnaru
Mar 31, 2014, 1:01:48 PM3/31/14
to pytho...@googlegroups.com
hello christophe, everybody,
attached is my best attempt to organize my code in a patch to stackforge,
with documentation etc.
unfortunately, i didn't find a way to join the gerrit group/project in order to
post myself my patch for review.
there seems to be a bug with soap in the demos:
class Root(controllers.RootController):
# Having a WSRoot on /ws is only required to enable additional
# protocols. For REST-only services, it can be ignored.
root = DemoRoot(webpath='/ws')
root.addprotocol('soap',
tns='http://example.com/demo',
typenamespace='http://example.com/demo/types',
baseURL='http://127.0.0.1:8080/ws/',
)
root.addprotocol('restjson')
ws = WSController(root)
if soap is not the first protocol added, the invokation will fail.
please instruct me how to continue in order that my patch be used.
thanks in advance,
alex
Christophe de Vienne
Mar 31, 2014, 2:26:36 PM3/31/14
to pytho...@googlegroups.com
Le 31/03/2014 19:01, Alex Bodnaru a écrit :
>
> hello christophe, everybody,
>
> attached is my best attempt to organize my code in a patch to stackforge,
> with documentation etc.
Thanks.
>
> hello christophe, everybody,
>
> attached is my best attempt to organize my code in a patch to stackforge,
> with documentation etc.
> unfortunately, i didn't find a way to join the gerrit group/project in
> order to
> post myself my patch for review.
do a gerrit review. Could give it a try ?
> there seems to be a bug with soap in the demos:
>
> class
> Root(controllers.RootController):
> # Having a WSRoot on /ws is only required to enable
> additional
> # protocols. For REST-only services, it can be
> ignored.
> root =
> DemoRoot(webpath='/ws')
>
> root.addprotocol('soap',
>
> tns='http://example.com/demo',
>
> typenamespace='http://example.com/demo/types',
>
> baseURL='http://127.0.0.1:8080/ws/',
>
> )
>
> root.addprotocol('restjson')
> ws =
> WSController(root)
>
> if soap is not the first protocol added, the invokation will fail.
>
> please instruct me how to continue in order that my patch be used.
you describe above. If this is indeed a bugfix, it should be a separate
patch.
Your patch should also not touch the demo scripts but rather provides
some unit tests that can be runned with tox and provide a good (if not
complete) coverage of you adapter.
See tox-tmpl.ini, and the framework specific tests in the test directory.
If you have questions on those please ask.
Thanks
Christophe
Doug Hellmann
Mar 31, 2014, 3:59:07 PM3/31/14
to pytho...@googlegroups.com
On Mon, Mar 31, 2014 at 2:26 PM, Christophe de Vienne
<cdev...@gmail.com> wrote:
> Le 31/03/2014 19:01, Alex Bodnaru a écrit :
>>
>> hello christophe, everybody,
>>
>> attached is my best attempt to organize my code in a patch to stackforge,
>> with documentation etc.
> Thanks.
>
>
>> unfortunately, i didn't find a way to join the gerrit group/project in
>> order to
>> post myself my patch for review.
> I think you only need to have a launchpad identity, configure gerrit and
> do a gerrit review. Could give it a try ?
There are some instructions for setting it up in the OpenStack wiki
<cdev...@gmail.com> wrote:
> Le 31/03/2014 19:01, Alex Bodnaru a écrit :
>>
>> hello christophe, everybody,
>>
>> attached is my best attempt to organize my code in a patch to stackforge,
>> with documentation etc.
> Thanks.
>
>
>> unfortunately, i didn't find a way to join the gerrit group/project in
>> order to
>> post myself my patch for review.
> I think you only need to have a launchpad identity, configure gerrit and
> do a gerrit review. Could give it a try ?
under https://wiki.openstack.org/wiki/GerritJenkinsGithub#Gerrit_Accounts
and https://wiki.openstack.org/wiki/Gerrit_Workflow#Account_Setup
> --
> You received this message because you are subscribed to the Google Groups "python-wsme" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to python-wsme...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> You received this message because you are subscribed to the Google Groups "python-wsme" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to python-wsme...@googlegroups.com.
Alex Bodnaru
Apr 1, 2014, 4:35:24 AM4/1/14
to pytho...@googlegroups.com
hello,
On Monday, March 31, 2014 9:26:36 PM UTC+3, Christophe de Vienne wrote:
Le 31/03/2014 19:01, Alex Bodnaru a écrit :
>
> hello christophe, everybody,
>
> attached is my best attempt to organize my code in a patch to stackforge,
> with documentation etc.
Thanks.
> unfortunately, i didn't find a way to join the gerrit group/project in
> order to
> post myself my patch for review.
I think you only need to have a launchpad identity, configure gerrit and
do a gerrit review. Could give it a try ?
i can login to launchpad, i can see the wsme-core project and group.
but where could i post the review?
but where could i post the review?
> there seems to be a bug with soap in the demos:
>
> class
> Root(controllers.RootController):
> # Having a WSRoot on /ws is only required to enable
> additional
> # protocols. For REST-only services, it can be
> ignored.
> root =
> DemoRoot(webpath='/ws')
>
> root.addprotocol('soap',
>
> tns='http://example.com/demo',
>
> typenamespace='http://example.com/demo/types',
>
> baseURL='http://127.0.0.1:8080/ws/',
>
> )
>
> root.addprotocol('restjson')
> ws =
> WSController(root)
>
> if soap is not the first protocol added, the invokation will fail.
>
> please instruct me how to continue in order that my patch be used.
I see you modified wsmeext/soap/protocol.py, probably to fix the issue
you describe above. If this is indeed a bugfix, it should be a separate
patch.
i have fixed the issue. an 'application/soap+xml' header had to be forced
on suds.
these, and a few skipped changes in this second patch.
the first modification of soap/protocol.py was to limit the need for explicit
webpath parameters, adding 2 defaults.
in the second patch, i streamlined this, and tg2 WSRootController does not
need any webpath related parameters anymore.
this is important to allow deployment to another domain.
on suds.
these, and a few skipped changes in this second patch.
the first modification of soap/protocol.py was to limit the need for explicit
webpath parameters, adding 2 defaults.
in the second patch, i streamlined this, and tg2 WSRootController does not
need any webpath related parameters anymore.
this is important to allow deployment to another domain.
Your patch should also not touch the demo scripts but rather provides
some unit tests that can be runned with tox and provide a good (if not
complete) coverage of you adapter.
the demo script had been improved, to allow turbogears cookie based login
before soap, and to add this header now.
also, as you see, inheriting from base was missing in the server side demo,
having the client script fail at the first run.
before soap, and to add this header now.
also, as you see, inheriting from base was missing in the server side demo,
having the client script fail at the first run.
See tox-tmpl.ini, and the framework specific tests in the test directory.
If you have questions on those please ask.
i'll definitely try.
Thanks
Christophe
i'm the one to thank,
alex
alex
Doug Hellmann
Apr 1, 2014, 10:44:58 AM4/1/14
to pytho...@googlegroups.com
On Tue, Apr 1, 2014 at 4:35 AM, Alex Bodnaru <alex...@gmail.com> wrote:
>
> hello,
>
>
> On Monday, March 31, 2014 9:26:36 PM UTC+3, Christophe de Vienne wrote:
>>
>> Le 31/03/2014 19:01, Alex Bodnaru a écrit :
>> >
>> > hello christophe, everybody,
>> >
>> > attached is my best attempt to organize my code in a patch to
>> > stackforge,
>> > with documentation etc.
>> Thanks.
>>
>>
>> > unfortunately, i didn't find a way to join the gerrit group/project in
>> > order to
>> > post myself my patch for review.
>> I think you only need to have a launchpad identity, configure gerrit and
>> do a gerrit review. Could give it a try ?
>
> i can login to launchpad, i can see the wsme-core project and group.
> but where could i post the review?
New patches can be published with the "git review" command. The
>
> hello,
>
>
> On Monday, March 31, 2014 9:26:36 PM UTC+3, Christophe de Vienne wrote:
>>
>> Le 31/03/2014 19:01, Alex Bodnaru a écrit :
>> >
>> > hello christophe, everybody,
>> >
>> > attached is my best attempt to organize my code in a patch to
>> > stackforge,
>> > with documentation etc.
>> Thanks.
>>
>>
>> > unfortunately, i didn't find a way to join the gerrit group/project in
>> > order to
>> > post myself my patch for review.
>> I think you only need to have a launchpad identity, configure gerrit and
>> do a gerrit review. Could give it a try ?
>
> i can login to launchpad, i can see the wsme-core project and group.
> but where could i post the review?
instructions on https://wiki.openstack.org/wiki/Gerrit_Workflow should
help you set up the tools you need to make that work.
Doug
lebouquetin
May 27, 2014, 1:53:34 PM5/27/14
to pytho...@googlegroups.com
Hello,
What is the status of this TG2 support patch ? I do not see anything on Github.
I'm interested in using it, and in writing unit tests or anything else required for its integration.
Damien
What is the status of this TG2 support patch ? I do not see anything on Github.
I'm interested in using it, and in writing unit tests or anything else required for its integration.
Damien
Christophe de Vienne
May 27, 2014, 3:20:18 PM5/27/14
to pytho...@googlegroups.com
Hello Damien,
We had no news from Alex about it, I guess he had no time to push a patch on gerrit.
If you want to help, the best would be to take the latest file posted by Alex on the group, add tests and push it to gerrit.
Once in gerrit a proper review from the wsme devs will take place and you will be able to polish the patch.
Cheers,
Christophe
We had no news from Alex about it, I guess he had no time to push a patch on gerrit.
If you want to help, the best would be to take the latest file posted by Alex on the group, add tests and push it to gerrit.
Once in gerrit a proper review from the wsme devs will take place and you will be able to polish the patch.
Cheers,
Christophe
Alex Bodnaru
Jun 10, 2014, 8:07:03 PM6/10/14
to pytho...@googlegroups.com
hello damien, christophe,
indeed it took me some time, but now i have a patch, complete with documentation, adjacent patches and even tests.
yet, i still don't know how to use geritt.
here is my patch.
alex
yet, i still don't know how to use geritt.
here is my patch.
alex
Reply all
Reply to author
Forward
0 new messages