Hi Michael,
for one pyramid_layout uses 'pyramid_layout' as category. So none of the
panels and layouts get registered because of change.
I don't know if there are other products right now because, I'm hunting
these issues in many of my Products.
I use different categories in my products as well. So I have to change
every product.
I see your point about the config object. So the category is used to
specify the callback interface or data requirements.
I didn't find this change in the What's new Page. It is mentioned in the
Backward Incompatibilities, but it should be mentioned in the What's new
page as well because it might break third party products used.
It took me some time to figure out why my Products didn't find the
main_template in 2.0 while it's working perfectly in 1.10.
Regards
Estartu
Am 12.03.21 um 17:19 schrieb Michael Merickel:
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 history in the
original ticket), and I could find some good reasons that it should be
"pyramid" which I don't think I explained well at all.
My main reason for changing it is that each scan() does have a contract with the decorator that needs to be
satisfied. All pyramid-compatible decorators expect the scanner to have a "config" attribute that
is a Pyramid Configurator object. That is the contract you get when you use "config.scan()". So if
a decorator wants the config object, shouldn't it register as the "pyramid" category or another
custom category passed to scan to guarantee it gets what it needs? This seems to be the only safe way to do
it with the scan api that is an umbrella search through the code.
I tend to prefer explicit over implicit in these types of things which is why I
advocated for the change and at the time no one advocated for keeping it. Which
packages are using different categories?
- Michael
On Mar 12, 2021, at 05:05, Gerhard Schmidt <esta...@augusta.de> wrote:
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 the pull request nor in the commit message.
In the related issue (which was closed in 2012) the final comment was
'I'm going to leave "all categories", as we've come to rely on it being the
default. If you want to limit it within your application, please pass a set of limiting
categories.'
The whole issuse is about using venusian outside of pyramid. So why change the
default in pyramid.
The change was 7 years after the issue was closed.
Regards
Estartu
Am 12.03.21 um 11:26 schrieb Steve Piercy:
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 regardless of category, specify config.scan(..., categories=None).
See https://github.com/Pylons/pyramid/pull/3510
That PR in turn fixed:
https://github.com/Pylons/pyramid/issues/3502
Which in turn referenced:
https://github.com/Pylons/pyramid/issues/495
I don't know if that answers your question, but please feel free to elaborate
if it does not. Thank you!
--steve
On 3/12/21 1:36 AM, Gerhard Schmidt wrote:
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, venusian asks the object
which categories are used and invoke all callbacks of the scanned package.
venusian.attach() stores all uses categories in an attribute of the object. So
the object knowns all used categories.
Some packages use different categories, so there callbacks are not called by
default. You have either call config.scan with all the categories used by your
product and all the packages you include or set categories=None when calling
the config.scan().
So is there a reason for this change, because it causes some issues when
migrating to pyramid 2.0.
Regards
Estartu
Am 01.03.21 um 04:40 schrieb Michael Merickel:
Yay, Pyramid 2.0 is out. Get it while it's hot!
If you're able to run 1.10.8 without deprecation warnings then you're in a
great spot to upgrade. Several warnings were added to 1.10.x releases to help
you prepare.
There's shockingly few backward-incompatible changes in this release, so don't
let it scare you. There IS a laundry list of new features. Here are a few
highlights:
- First release to drop Python 2, as well as 3.4 and 3.5.
- New security system for authentication/authorization. The legacy API is
deprecated but available and backward compatible. ACLs and principals are not
going away, but the policies are merged and restructured slightly which should
be more consumable and flexible for users.
- Several defaults have changed, such as serializing sessions using JSON
instead of Pickle.
- Cookiecutter and tutorials updated with new pytest fixtures.
- The "pyramid.compat" module is gone.
Read the "What's New in Pyramid 2.0" document for a comprehensive list of
changes and upgrading notes:
https://docs.pylonsproject.org/projects/pyramid/en/2.0-branch/whatsnew-2.0.html
<https://docs.pylonsproject.org/projects/pyramid/en/2.0-branch/whatsnew-2.0.html>
2.0 release documentation:
https://docs.pylonsproject.org/projects/pyramid/en/2.0-branch/
<https://docs.pylonsproject.org/projects/pyramid/en/2.0-branch/>
You can install it via PyPI:
pip install Pyramid==2.0
As always report any issues to the issue tracker (or here on the mailing list).
https://github.com/Pylons/pyramid/issues
<https://github.com/Pylons/pyramid/issues>
Special thanks to a few people specifically for their excellent work on this
release:
- Theron Luhn
- Bert JW Regeer
- Steve Piercy
Thanks for everyone's efforts as well as support in getting this work done!
- Pyramid core developers
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
pylons-discuss+unsubscr...@googlegroups.com
<mailto:pylons-discuss+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/pylons-discuss/14F179EB-F647-42B7-845A-6091E1AFF697%40gmail.com
<https://groups.google.com/d/msgid/pylons-discuss/14F179EB-F647-42B7-845A-6091E1AFF697%40gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pylons-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/pylons-discuss/c9c1bd77-0a30-304e-8036-c5aa760acca9%40augusta.de.
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pylons-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/pylons-discuss/3f43cdcd-2f54-3c6f-4b4f-7d08f9daf023%40augusta.de.
