Estartu,
Thanks for bringing up the issue.
The initial reason I looked into changing it is because I had other venusian
packages that I did not want scanned and when I dove into the details I could
not find a good reason why things were the way they were (you can see I looked
through the
Yes, it is much closer to your pyramid_openapi3 demos. I'm not sure that
project is a good candidate for my requirements or bandwidth, but I will
dig into it - thanks!
On Friday, March 12, 2021 at 4:52:45 PM UTC-5 Steve Piercy wrote:
> My first thought was to use docstrings and Sphinx, but
I had a small Pyramid project which has grown into a much larger one.
Many Views service multiple Routes (multiple calls to `@view_config()`),
typically offering a default HTML version on a "bare" url, and a JSON
version with a ".json" suffix to the url.
Documenting these routes has become
My first thought was to use docstrings and Sphinx, but I don't think that's
what you want.
It sounds like you want to document an API, something like pyramid_openapi3.
https://github.com/Pylons/pyramid_openapi3/
RealWorld.io app API Demo (it might take a while to start up the app, as it is
Hallo Steve,
I have found the change but there is not reason why this change is
needed. It simple states the change. What is the reason behind the change.
Are there security issues? Which added benefits does it provide? Why is
categories=None a bad idea?
These question aren't answered in
Hi,
thanks for the work.
is there a reason why Configurator.scan() now has a default value of
('pyramid',) for categories. In pyramid 1 the default was None.
The change causes that only callbacks in category 'pyramid' are called
by default. If the scanner called with categories=None,
>From the release notes:
https://docs.pylonsproject.org/projects/pyramid/en/latest/changes.html#backward-incompatibilities
pyramid.config.Configurator.scan will no longer, by default, execute Venusian
decorator callbacks registered for categories other than 'pyramid'. To find any
decorator
