Cornice 0.6 released
Tarek Ziadé
I guess this is the proper place for this kind of announcement ...
=> We've released Cornice 0.6
Cornice provides helpers to build & document REST-ish Web Services
with Pyramid.
This version has:
- multiple bug fixes
- a Paster template to quickly start a new Cornice project
- a tutorial & a full new example in examples/
You can try out the tutorial at http://packages.python.org/cornice/tutorial.html
The main benefits of Cornice are:
- automatic handling of some HTTP errors - Ask yourself: is your app
handling properly 405 or 406 errors?
- automatic web service documentation via a Sphinx extension.
- a simple way to validate and convert requests data, and return
structured 400 responses.
Check it out :
- Documentation - http://packages.python.org/cornice
- PyPI - http://pypi.python.org/pypi/cornice
- Repository - https://github.com/mozilla-services/cornice
We'd love feedback & new contributors !
Cheers
Tarek
--
Tarek Ziadé | http://ziade.org
Tony Theodore
> Hey,
>
> I guess this is the proper place for this kind of announcement ...
>
> => We've released Cornice 0.6
>
> Cornice provides helpers to build & document REST-ish Web Services
> with Pyramid.
Perfect! I'd just decided to try ember.js[1] for my next project and
was wondering how to go about it.
Thanks,
Tony
Steve Schmechel
--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-...@googlegroups.com.
To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Chris McDonough
> Following the tutorial did not work for me using "pip", but worked
> fine using "easy_install" (distribute).
> It was done with Python 2.7 in a virtual environment created with
> --no-site-packages.
The error message doesn't seem to show anything useful. I'm pretty
clueless. There's a tempfile mentioned as "install-record.txt"; maybe
it has information.
> Also, you may want to look at "pinning" the dependency versions for
> Cornice. It seems to pull in the latest of everything, which will
> likely be a problem at some point. (It pulled in the just-released
> Pyramid version 1.3a3.)
Making a package author responsible for pinning dependencies is usually
a really poor idea, because it means the package cannot be used in
configurations where it actually does work but an old pin or a
too-conservative pin prevents it. In general, if folks want guaranteed
stability and repeatability, they are going to need to maintain their
own version pins (using a requirements.txt, a buildout.cfg, or a
self-hosted index).
- C
Tarek Ziadé
Following the tutorial did not work for me using "pip", but worked fine using "easy_install" (distribute).It was done with Python 2.7 in a virtual environment created with --no-site-packages.(The "pro-Pip" people claim that problems encountered with Pip are due to authors not setting things up correctly, and that Pip won't "half install" things. Then many packages on PyPI must be broken, because in my experience Pip only installs things successfully less than half the time.)
Weird. I had other issues with Paste* packages at some point in Distribute. If you investigate I am interested. One thing to try would be to install Paste* packages manually before you install Cornice -- if it works, I'd suspect a cache issue.
Also, you may want to look at "pinning" the dependency versions for Cornice. It seems to pull in the latest of everything, which will likely be a problem at some point. (It pulled in the just-released Pyramid version 1.3a3.)
yeah though topic. I tend to agree with Chris here.. In any case Cornice is very lightweight and should work on most pyramid versions unless the way views are registered drastically change. In that case, I'll introduce version ranges I guess.
I haven't gotten much past the "Hello World" screen yet, but I will be digging further soon.
Should future conversation remain on the pylon-discuss list or move to another venue?
I guess it's fine here, unless Chris and other people managing the Pylons/Pyramid project think it's innapropriate, in that case I could create another one.
Cheers
Tarek
Chris McDonough
>
> I guess it's fine here, unless Chris and other people managing the
> Pylons/Pyramid project think it's innapropriate, in that case I could
> create another one.
No it's fine here to me, glad to see it being discussed!
- C
Gael Pasgrimaud
On Wed, Dec 21, 2011 at 11:24 AM, Tarek Ziadé <ziade...@gmail.com> wrote:
> We'd love feedback & new contributors !
Looks like a clever way to build some APIs. I have a project where I
may switch to cornice. But I have a few questions.
First, are you planning to add a support for class based views ? I'd
like to define my services like this:
@cornice.service(path='/users')
class User(object):
def __init__(self, request):
self.request = request
def get(self):
"""do get"""
Where get / post / put / delete and index (to get a listing) routes
will be automatically added if they are implemented. This is something
that missing from Pylons the framework (at least for me).
Does cornice support sub resources ? (eg: with a path like /users/{id}/pages/)
And the last one. Can we use the pyramid authentication/authorisation
stuff with cornice ?
>
> Cheers
> Tarek
>
> --
> Tarek Ziadé | http://ziade.org
>
Tarek Ziadé
Hi,
Looks like a clever way to build some APIs. I have a project where I
On Wed, Dec 21, 2011 at 11:24 AM, Tarek Ziadé <ziade...@gmail.com> wrote:
> We'd love feedback & new contributors !
may switch to cornice. But I have a few questions.
First, are you planning to add a support for class based views ? I'd
like to define my services like this:
@cornice.service(path='/users')
class User(object):
def __init__(self, request):
self.request = request
def get(self):
"""do get"""
Where get / post / put / delete and index (to get a listing) routes
will be automatically added if they are implemented. This is something
that missing from Pylons the framework (at least for me).
I have never thought of that but why not ? using the method names instead of explicit decorator seems neat.
The only caveat I see is that we actually pass options to decorators, like particular renderers, permissions, validators etc.
So I wonder where we'd put them in the case of a class, for each service,
Does cornice support sub resources ? (eg: with a path like /users/{id}/pages/)
I don't know what sub resources are. If it's just jokers like {id} in the path then yes, you can and
you will find them back in request.matchdict
And the last one. Can we use the pyramid authentication/authorisation
stuff with cornice ?
yes. you can define permissions, see for example:
https://github.com/mozilla-services/demoapp/blob/master/demoapp/views.py
and acl factories, see
https://github.com/mozilla-services/cornice/blob/master/cornice/service.py#L98
(sorry the latter is not really documented)
>
> Cheers
> Tarek
>
> --
> Tarek Ziadé | http://ziade.org
>
> --
> You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
> To post to this group, send email to pylons-...@googlegroups.com.
> To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
>
--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-...@googlegroups.com.
To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Gael Pasgrimaud
>
>
> On Wed, Dec 21, 2011 at 11:00 PM, Gael Pasgrimaud <ga...@gawel.org> wrote:
>>
>> Hi,
>>
>> On Wed, Dec 21, 2011 at 11:24 AM, Tarek Ziadé <ziade...@gmail.com>
>> wrote:
>> > We'd love feedback & new contributors !
>>
>> Looks like a clever way to build some APIs. I have a project where I
>> may switch to cornice. But I have a few questions.
>>
>> First, are you planning to add a support for class based views ? I'd
>> like to define my services like this:
>>
>> @cornice.service(path='/users')
>> class User(object):
>>
>> def __init__(self, request):
>> self.request = request
>>
>> def get(self):
>> """do get"""
>>
>>
>> Where get / post / put / delete and index (to get a listing) routes
>> will be automatically added if they are implemented. This is something
>> that missing from Pylons the framework (at least for me).
>>
>
> I have never thought of that but why not ? using the method names instead of
> explicit decorator seems neat.
>
> The only caveat I see is that we actually pass options to decorators, like
> particular renderers, permissions, validators etc.
>
> So I wonder where we'd put them in the case of a class, for each service,
>
Here is a proof of concept (can be improved)
http://friendpaste.com/4MnSHaRPkNU9RCtHkd4ggU
>
>
>>
>> Does cornice support sub resources ? (eg: with a path like
>> /users/{id}/pages/)
>
>
> I don't know what sub resources are. If it's just jokers like {id} in the
> path then yes, you can and
> you will find them back in request.matchdict
>
>
>
>>
>> And the last one. Can we use the pyramid authentication/authorisation
>> stuff with cornice ?
>
>
> yes. you can define permissions, see for example:
>
> https://github.com/mozilla-services/demoapp/blob/master/demoapp/views.py
>
> and acl factories, see
>
> https://github.com/mozilla-services/cornice/blob/master/cornice/service.py#L98
>
> (sorry the latter is not really documented)
>
>
Nice. I guess I'll try to switch one day (time is always missing..)
Tarek Ziadé
Here is a proof of concept (can be improved)
http://friendpaste.com/4MnSHaRPkNU9RCtHkd4ggU
I like it -- I think it solves a problem I had with using a bunch of functions - having to keep some globals around.
If you want to fork us and work on a pull request / https://github.com/mozilla-services/cornice
I'd love to see this way of describing services added
Thanks
Tarek
Steve Schmechel
Steve Schmechel
--
Chris McDonough
> Maybe I used the wrong term in "pinning". Or maybe the tutorial
> should be a special case.
>
>
> Say I write some code today that relies on Cornice version 0.6
> and it works splendidly. Then in a few weeks/months I decide to
> write something similar with Cornice version 0.6 (assuming that
> is still the latest version) and I start by doing "pip install
> Cornice", there is no guarantee that I get the same set of code
> to start with? I might get Cornice version 0.6 running on
> Pyramid 1.4a1?
>
>
> So I need to create the full dependency list in my new project,
> and manually install what I need as "pip install Cornice" is no
> longer the easy option, right?
pip install -r requirements.txt likely. Or a buildout. Or a private
index with the right versions in it.
> That sounds reasonable (I guess), as it implies that the Cornice
> author makes no real assertion that their software works any
> better (bug free) with any particular version of Pyramid past,
> present, or future. It is up to me as the developer to run or
> create all the tests that assure things work together. (Or copy
> a previously working environment.)
True.
Unlikely. PyPI is the wild west. Using it usually produces something
that works only by the grace of god and diligence about dependencies by
developers. And for developers who have Pyramid as a dependency, it
will either work (very likely, Pyramid doesn't introduce backwards
incompatible stuff without plenty of warning), or it won't.. if it
doesn't work, then someone will complain, and the developer will either
fix it, or he won't. That's about as much promise about using PyPI to
install Pyramid as I'm willing to offer. That said, I can't even
remember the last time someone got a configuration from PyPI that didn't
work, because to one degree or another, we are in control of almost all
of Pyramid's dependencies and we try to make sure the latest stuff all
works together.
> If I want to try a Development Environment with the latest alpha
> or beta Pyramid, I will go in and change the dependency and
> upgrade. (I don't might things breaking as much when I am the
> idiot who initiated it. :-)
>
>
> Anyway, that is not really the problem I was having, and Cornice
> seems to work fine with the latest Pyramid code (once everything
> is installed). I'm just saying it makes me nervous when things
> pull in the "latest" automatically.
You aren't the only one who feels this way. PyPI provides really,
really poor control to authors over what to make available for download.
It basically boils down to either "upload it or don't", there's no
middle ground or way to hide anything. It's totally pointless to make
an alpha release of software that people can't install, so I choose to
upload.
For the record, buildout (zc.buildout) has an option prefer_final or
something, which ignores releases that smell like betas or alphas or
dev2938929348729 or whatever. easy_install and pip should likely grow
something like it.
- C
Steve Schmechel
bin/easy_install -i http://dist.repoze.org/bfg/current/simple \ repoze.bfg
- C
Chris McDonough
> Just curious, did the idea of separate indexes for current and
> development versions go away?
> I remember:
> bin/easy_install -i http://dist.repoze.org/bfg/current/simple \
> repoze.bfg
> Was it too hard to manage the private indexes?
Yes. And no one really remembered to use them anyway. And when they
did, they complained that those indices didn't have everything PyPI had
in them. None of the install tools allow you to use more than one index
for everything.
> Pyramid has separate documentation for version 1.0, 1.1, 1.2, and
> 1.3.
> But if you follow any of them you end up running latest code due to
> this step in every version:
> $ bin/easy_install pyramid
Yup.
> I guess this happened in old BFG documentation as well, since
> old versions
> were not updated updated to use a "maintenance index" after a new
> version was released. However, there was a separation between current
> and
> development indexes.
>
>
> Maybe Pyramid is more stable now and a separate development index
> is not worth the effort. (And the documentation is accurate right out
> of
> the gate, which is extraordinary.)
Most people when hit with their first "oh shit, PyPI changed" moment
learn to pin requirements. And they learn to adjust docs based on the
way they do that. Additionally, most people who haven't run into this
are almost always wanting to install the latest version anyway, so it
generally works out. Legislating all this is too much work.
- C
Robert Forkel
methods. I also like the idea of the @service decorator (it would be
easier to understand in particular because of the analogy to the
@action decorator of pyramid_handlers).
One more thing which bothered me when looking at the Service
implementation: Why the 'acl' parameter and not a full context
factory? I'm playing with cornice to add an API to an existing webapp,
so I already have these context factories around but cannot pass them
into a cornice service.
regards
robert
Tarek Ziadé
One more thing which bothered me when looking at the Service
implementation: Why the 'acl' parameter and not a full context
factory? I'm playing with cornice to add an API to an existing webapp,
so I already have these context factories around but cannot pass them
into a cornice service.
I don't see any good reason -- so I'd be tempted to fix this. I am cc'ing Ryan that did that first implementation
Cheers
Tarek
Alexis Metaireau
However, part of what you're doing with the code you submitted is
already handled by what we've done in cornice (https://github.com/
mozilla-services/cornice/blob/master/cornice/service.py#L87) we could
for instance deal with a Service class internally to define the routes
and the appropriate callables.
I've done something similar for Flask in a flask-rest:
https://github.com/ametaireau/flask-rest/blob/master/flask_rest.py,
the definition looks like this: https://github.com/spiral-project/ihatemoney/blob/master/budget/api.py#L63
I went for get, list, add, update and delete as name of the methods
because HTTP verbs carry some meaning with them (for instance, PUT
does not means "update", but we can also stick to the http methods +
list for the index.
What do you think?
Wyatt Baldwin
Why not just use the built-in @view_config decorator?
Gael Pasgrimaud
Don't know if you have tried to build an api with more than one format
but when you have 2 or 3 decorators with a lot of parameters per
method this starts to become a bit... unreadable.
A lot of parameters can be set at the class level or automatically set
for you if you want to define a RESTFul resource:
- route name - always the same for a resource (two routes in fact:
collection/element)
- http method - resolved from method name
- a global permission - redefined for each method if needed
- a default renderer - json
- etc.
FYI I've added this implementation and Alexis has added a few docs:
https://github.com/mozilla-services/cornice/blob/master/docs/source/resources.rst
>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/pylons-discuss/-/z0zUTwbJnSAJ.
Robert Forkel
application, but i'm not sure whether this is an inteded use case.
Right now this is made difficult by things like the registration of a
static view at 'static' in cornice's 'includeme' (because it
overwrites a view my base app already registered).
So should cornice be used only for standa
Robert Forkel
Should cornice be only used for standalone apps?
regards
robert
Alexis Métaireau
> i'm trying to use cornice to add an API to an existing pyramid
> application, but i'm not sure whether this is an inteded use case.
there is a static view registered but it should be the app
responsability to do this, not cornice's. I'm fixing this.
Thanks for the feedback,
Alexis
Tarek Ziadé
We should remove it altogether. Iirc this is not used anymore.
--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to pylons-discuss+unsubscribe@googlegroups.com.
Heltem
Any news about it and next release ? Roadmap ?
Tarek Ziadé
On Sunday, March 11, 2012 10:38:11 AM UTC+1, Heltem wrote:
I am really interested in cornice.
Any news about it and next release ? Roadmap ?
We should cut a release soon-ish. We don't have any formal roadmap, you can have a look at https://github.com/mozilla-services/cornice/issues?sort=created&direction=desc&state=open If you have any feature request or suggestion let us know here, on in the tracker Thanks