We typically handle it like this...
For these routes/files
/v2/veryimportantroute <> views/api/v2.py
/v3/veryimportantroute <> views/api/v3.py
we tend to proxy the actual API functions to something like
lib.api.veryimportantroute.py
def v2()
def v3()
the url routing is
On Mon, Apr 24, 2017 at 10:04 AM, Oleg Borisenko wrote:
> Hello. I want to get API-versioning functionality and I wonder how to do it
> in Pyramid correctly.
> Conditions:
> 1) I want to have two simultaneously working APIs
> 2) I want to have the following notation:
>
venusian 1.x.y has been released.
Here are the changes:
- Updated to using py.test instead of nosetest, and added support for Python
3.4 -> 3.6
- Make scanning more resilient of metaclasses that return proxies for any
attribute access.
- Fix bug where using the same venusian decorator on
> On Apr 24, 2017, at 19:10, Bert JW Regeer wrote:
>
> venusian 1.x.y has been released.
>
> […]
That off course should say venusian 1.1.0, templating fail on my part.
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To
I am one of the active maintainers of Gunicorn. I've worked a lot with
Pyramid and reviewed or written many of the changes to Gunicorn's support
for Paster over the last couple years. I wanted to chime in mostly to say
that I'm following along, but I haven't had a chance to figure out exactly
Looking at it, the —stop-daemon would send a kill signal to the process, there
was/is no extra processing that is done when that signal was sent, it would
insta-kill the server.
Just having the windows service manager kill the task works just fine, and is
what it is designed to do.
Bert
> On
Hello. I want to get API-versioning functionality and I wonder how to do it
in Pyramid correctly.
Conditions:
1) I want to have two simultaneously working APIs
2) I want to have the following notation:
/v2/veryimportantroute
/v3/veryimportantroute
/veryimportantroute - this one should by
Gunicorn does not support Windows yet.
On Mon, Apr 24, 2017, 00:38 Laurent DAVERIO wrote:
> Maybe gunicorn could be used too. It is compatible with Python 3, and it
> seems to have a daemon mode.
>
> One trap I recently fell into, is that it's not compatible with:
>
> >
Maybe gunicorn could be used too. It is compatible with Python 3, and it
seems to have a daemon mode.
One trap I recently fell into, is that it's not compatible with:
> [server:main]
> use = egg:waitress#main
> listen = 127.0.0.1:6543 [::1]:6543
you have to use the old syntax, ie:
>