From david.bell at isotoma.com Wed Jul 2 15:57:17 2014 From: david.bell at isotoma.com (David Bell) Date: Wed, 02 Jul 2014 16:57:17 +0100 Subject: [spyne] Writing tests for a web service Message-ID: <53B42BDD.3050306@isotoma.com> Hi, As noted in: https://github.com/arskom/spyne/issues/367 I'm trying to write tests for a django hosted spyne service. What is the recommended way of doing this that fits with django's standard testing format? Many thanks Dave Bell -- Isotoma, Open Source Software Consulting - http://www.isotoma.com Tel: 01904 567340, Mob: 0795 225 9062, Fax: 020 79006980 Postal Address: Tower House, Fishergate, York, YO10 4UA, UK Registered in England. Company No 5171172. VAT GB843570325. Registered Office: Tower House, Fishergate, York, YO10 4UA, UK From burak.arslan at arskom.com.tr Wed Jul 2 19:14:29 2014 From: burak.arslan at arskom.com.tr (Burak Arslan) Date: Wed, 02 Jul 2014 22:14:29 +0300 Subject: [spyne] Writing tests for a web service In-Reply-To: <53B42BDD.3050306@isotoma.com> References: <53B42BDD.3050306@isotoma.com> Message-ID: <53B45A15.2070801@arskom.com.tr> Hi Dave On 02/07/14 18:57, David Bell wrote: > Hi, > > As noted in: https://github.com/arskom/spyne/issues/367 > I'm trying to write tests for a django hosted spyne service. > > What is the recommended way of doing this that fits with django's > standard testing format? > I've got no idea about Django, but in Spyne, you can call services locally using the NullServer. There are links to examples in this Stackoverflow answer: http://stackoverflow.com/questions/19383937/testing-spyne-application hth, burak From burak.arslan at arskom.com.tr Mon Jul 7 00:19:14 2014 From: burak.arslan at arskom.com.tr (Burak Arslan) Date: Mon, 07 Jul 2014 03:19:14 +0300 Subject: [spyne] Spyne Plugin Architecture Message-ID: <53B9E782.1000502@arskom.com.tr> Dear All, A pull request[1] that can't be merged automatically for Spyne's Django integration got me thinking: We need a documented way of publishing Spyne code outside of central Spyne repo. Why? The main reason is that I'm not scalable :) It's impossible for me to do QA on code that integrates with a technology I'm not familiar with. Django is one example of this, AMQP[2] is another. I'm hoping that such requests will grow in time, so I don't want to be a bottleneck holding these ideas back. Is this at all possible? As it stands, the different protocols and transports currently in Spyne's source distribution are already nicely decoupled from each other -- to the point that e.g. the SOAP stack can fully support Python3 whereas the DictDocument stack doesn't yet. There's nothing stopping us from spinning the SOAP code in Spyne off to a package called spyne-soap. So my efforts towards of making it easy to write decoupled Spyne code seems to be working so far. How will it work, exactly? That's the exact subject I'm hoping get input about. Current open questions: 1) Should we use namespace packages (PEP 420[3] (For 2.7, see [4])) or just do what Flask does and let the package name be the same as its Pypi handle? (e.g. spyne-django will contain the spyne_django package instead of the spyne package with additional subpackages) 2) How should we integrate the test suites of Spyne and its child packages? We'd like to keep the current status quo where every commit gets tested against every integration by Travis-CI. My plan is to make it the the big feature of 2.12. Any other issues you see about this? Your feedback is most welcome. Best regards, Burak [1]: https://github.com/arskom/spyne/pull/363 [2]: https://github.com/arskom/spyne/issues/374 [3]: http://legacy.python.org/dev/peps/pep-0420/ [4]: http://legacy.python.org/dev/peps/pep-0420/#namespace-packages-today From rinatshigapov at gmail.com Mon Jul 7 12:15:59 2014 From: rinatshigapov at gmail.com (Rinat Shigapov) Date: Mon, 7 Jul 2014 16:15:59 +0400 Subject: [spyne] Spyne Plugin Architecture Message-ID: > 1) Should we use namespace packages (PEP 420[3] (For 2.7, see [4])) or just do what Flask does and let the package name be the same as its Pypi > handle? (e.g. spyne-django will contain the spyne_django package instead > of the spyne package with additional subpackages) According to PEP8: "Python packages should also have short, all-lowercase names, although the use of underscores is discouraged." I think PEP 0420 is appropriate feature for splitting the project. Does it work in setuptools develop mode under Python 2.7? Do you think that namespace like spyne.plugins or spyne.extensions is better than just spyne? I'm not sure if name 'plugin' is right one for subpackages. Will Spyne core load plugins? Or user will import interface extensions provided by subpackages? 2) How should we integrate the test suites of Spyne and its child > packages? We'd like to keep the current status quo where every commit > gets tested against every integration by Travis-CI. I found following issue https://github.com/travis-ci/travis-ci/issues/631 . So Travis doesn't support build triggers for child projects. It's possible to organize tox environment for each extension in Spyne core project. These environments should run tests from master branch of each extension. And each extension project should run tests with spyne core master branch. This approach allows to track incompatibilities between the core and extensions from both sides. -- Regards, Rinat Shigapov -------------- next part -------------- An HTML attachment was scrubbed... URL: From burak.arslan at arskom.com.tr Mon Jul 7 14:59:05 2014 From: burak.arslan at arskom.com.tr (Burak Arslan) Date: Mon, 07 Jul 2014 17:59:05 +0300 Subject: [spyne] Spyne Plugin Architecture In-Reply-To: References: Message-ID: <53BAB5B9.6030101@arskom.com.tr> On 07/07/14 15:15, Rinat Shigapov wrote: > > 1) Should we use namespace packages (PEP 420[3] (For 2.7, see > [4])) or > > just do what Flask does and let the package name be the same as > its Pypi > handle? (e.g. spyne-django will contain the spyne_django package > instead > of the spyne package with additional subpackages) > > > According to PEP8: > "Python packages should also have short, all-lowercase names, > although the use of underscores is discouraged." > > I think PEP 0420 is appropriate feature for splitting the project. Agreed. > Does it work in setuptools develop mode under Python 2.7? It should, from what I gather all it does is to extend sys.path on import. > Do you think that namespace like spyne.plugins or spyne.extensions is > better than just spyne? > > I'm not sure if name 'plugin' is right one for subpackages. Will Spyne > core load plugins? Or user will import interface extensions provided > by subpackages? I don't like the idea of using a separate package for plugins because doing so would hinder our ability to move code between plugins and Spyne core. Mature and (almost) universally used plugins could be moved inside Spyne core, whereas e.g. code that needs its own release agenda could be spun off without disrupting its users' workflow. So we should make a concious effort towards not breaking code that works. The idea of a Spyne plugin should be that it contains code that would normally go into Spyne. Installing spyne-django, would mean importing from spyne.server.django just would work. > > 2) How should we integrate the test suites of Spyne and its child > packages? We'd like to keep the current status quo where every commit > gets tested against every integration by Travis-CI. > > > I found following issue > https://github.com/travis-ci/travis-ci/issues/631 . So Travis doesn't > support build triggers for child projects. > > It's possible to organize tox environment for each extension in Spyne > core project. These environments should run tests from master branch > of each extension. And each extension project should run tests with > spyne core master branch. This approach allows to track > incompatibilities between the core and extensions from both sides. I agree. Do you think having a plugin's name in Spyne's test script could be considered as a vote of confidence towards that project? Perhaps we should be a bit picky about what we're testing against. We certainly need rules around it as I would not prefer to get a "BROKEN!!!" email from travis because someone isn't doing the right thing. Having separate test scripts for separate subsystems also simplifies a lot of things. A huge chunk of Spyne's current setup.py is about testing -- i'd love to see that script get simpler. Another point: Docs!!! I guess they are going to be harder to manage ourselves. What do you think? I say just offload it to readthedocs, at least initally. Once we successfully spin off spyne-django, I'll prepare a spyne-project-template project so that there's an easy starting point for other people who want to write portable Spyne plugins. Best, Burak -------------- next part -------------- An HTML attachment was scrubbed... URL: From burak.arslan at arskom.com.tr Tue Jul 8 12:22:47 2014 From: burak.arslan at arskom.com.tr (Burak Arslan) Date: Tue, 08 Jul 2014 15:22:47 +0300 Subject: [spyne] Spyne Plugin Architecture In-Reply-To: References: <53BAB5B9.6030101@arskom.com.tr> Message-ID: <53BBE297.1080605@arskom.com.tr> On 07/08/14 10:58, Rinat Shigapov wrote: > > > I agree. Do you think having a plugin's name in Spyne's test > script could be considered as a vote of confidence towards that > project? Perhaps we should be a bit picky about what we're testing > against. We certainly need rules around it as I would not prefer > to get a "BROKEN!!!" email from travis because someone isn't doing > the right thing. > > > Yes, policy is great idea. If things get worse Travis has allowed > failures feature > http://docs.travis-ci.com/user/build-configuration/#Rows-That-are-Allowed-To-Fail > That's not as fine-grained as I'd like, but it's a start. > > > Another point: Docs!!! I guess they are going to be harder to > manage ourselves. What do you think? I say just offload it to > readthedocs, at least initally. > > > What advantages does readthedocs provide except slick design? > Our options: 1) Remove plugin docs from spyne.io and let every plugin author decide what they want to do with the docs. We don't impose a doc format or anything. They may or may not provide a link to the docs. If they do, we will put the link inside Spyne core's docs. 2) Keep plugin docs closer to our chest, publish the reference from within Spyne docs -- i.e. exactly like we're doing today. This needs a custom daemon running somewhere with credentials to commit to spyne.github.io though. I don't like this option that much. Readthedocs is just the most accessible example today. It's easy to use, but sphinx is also easy to use, I agree it's not doing that much. Having a slick design important though :) best, burak -------------- next part -------------- An HTML attachment was scrubbed... URL: From burak.arslan at arskom.com.tr Tue Jul 8 15:03:42 2014 From: burak.arslan at arskom.com.tr (Burak Arslan) Date: Tue, 08 Jul 2014 18:03:42 +0300 Subject: [spyne] Julython Message-ID: <53BC084E.40908@arskom.com.tr> Hello All, We're participating in Julython! Pull request authors (both current and future :)), please register (very easy via github) to add more points to Spyne. We're currently in 10th place globally in the large projects category: http://www.julython.org/projects/ Here's a link to the project: http://www.julython.org/projects/gh-arskom-spyne/ Have fun! Best regards, Burak From kamil.galuszka at 4dpipeline.com Sun Jul 20 10:13:04 2014 From: kamil.galuszka at 4dpipeline.com (=?UTF-8?Q?Kamil_Ga=C5=82uszka?=) Date: Sun, 20 Jul 2014 12:13:04 +0200 Subject: [spyne] Robots list doesn't work? Message-ID: Hi, Is this lists working lists.spyne.io/archives/robots/ ? Seems that there is nothing on July. Is it broken or just wasn't used by anyone? Cheers Kamil Ga?uszka -------------- next part -------------- An HTML attachment was scrubbed... URL: From burak.arslan at arskom.com.tr Sun Jul 20 10:25:16 2014 From: burak.arslan at arskom.com.tr (Burak Arslan) Date: Sun, 20 Jul 2014 13:25:16 +0300 Subject: [spyne] Robots list doesn't work? In-Reply-To: References: Message-ID: <53CB990C.3060303@arskom.com.tr> On 07/20/14 13:13, Kamil Ga?uszka wrote: > Hi, > > Is this lists working lists.spyne.io/archives/robots/ > ? > > Seems that there is nothing on July. Is it broken or just wasn't used > by anyone? > no it's functional, i just seem to have turned off the archiving at that time, thinking it was pointless -- everyting there can be found in the commit logs and CI logs. I should probably remember to delete the archive as well. best, burak -------------- next part -------------- An HTML attachment was scrubbed... URL: From russell+spyne at stuart.id.au Tue Jul 29 08:10:10 2014 From: russell+spyne at stuart.id.au (russell+spyne at stuart.id.au) Date: Tue, 29 Jul 2014 18:10:10 +1000 Subject: [spyne] sypne in Debian Message-ID: Just letting you now spyne-2.11.0 is currently sitting in Debian's NEW queue, awaiting Ftp Master approval. The source required no patching at all, which is nice.