New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pyramid 2.0 possible feature list #2362

Open
mmerickel opened this Issue Feb 21, 2016 · 28 comments

Comments

Projects
None yet
@mmerickel
Member

mmerickel commented Feb 21, 2016

I'm starting here a little 2.0 wishlist. I have no idea if an issue will be a good medium for the discussion but here goes. None of these are guaranteed to make the cut. There is no timeline for this yet. Personally I'm interested in MINOR incompatibilities that are large enough that we have refused to do until now (i.e. nothing that will require a fundamental redesign of a Pyramid app for a user).

Please keep the discussion away from here and in separate issues. Let's focus on simply compiling a list of possibilities.

likely

  • Remove check_csrf view predicate in favor of require_csrf (already deprecated).
  • Remove custom_predicates from config.add_view and view_config (already deprecated).
  • Remove config.set_request_property (already deprecated).

interesting, let's open an issue and talk about it

  • Drop Python 2 support. #2903
  • Switch the ISession contract from pickleable objects to something more secure and portable like json. #2709
  • Separate CSRF tokens from the ISession into something else implementable without a session. #1573
  • Something to do with route prefixes so that it's possible to use config.include without the base url inside having a / suffix. #406, #1639
  • Drop PasteDeploy in favor of a better loading system. #2419
  • Fix predicate factories to accept a standardized info object instead of config. Currently the only purpose of this argument is for config.maybe_dotted but it's poor practice to pass the ephemeral config object around. #2535
  • Drop the use_tweens argument to request.invoke_subrequest in order to make the nested request pipeline more sane. #2606

interesting but unlikely without a champion to start the discussion

  • Deprecate remember/forget APIs in favor of a pattern that fits better with non-cookie workflows.
  • Something to do with identity and auth-api post mortem?
  • Remove pcreate and default scaffolds. #2384
  • Add a public API at the top-level pyramid namespace. For example pyramid.view_config, pyramid.Configurator, etc. This would greatly assist in maintainability of the public API for people using IDEs like pycharm where they may not be checking the docs to ensure an API is public. Probably use a lazy-instantiator like apipkg for this. #2387
  • Re-work view_config to namespace arguments to be more clear about options versus predicates.
  • Re-work config.add_view, config.add_forbidden_view, config.add_notfound_view to accept only kwargs. Almost all of the parameters are indistinguishable from user-defined view options, so they could be treated all the same.
  • Separate NotFound and Forbidden exceptions from HTTPNotFound and HTTPForbidden. This would undo previous work to merge them in order to make exception views more understandable.

other proposals

  • Restrict the request methods on add_view by default to GET and POST. #2796

@mmerickel mmerickel added this to the 2.0 milestone Feb 21, 2016

@mmerickel mmerickel changed the title from Pyramid 2.0 features to Pyramid 2.0 possible feature list Feb 21, 2016

@bertjwregeer

This comment has been minimized.

Show comment
Hide comment
@bertjwregeer

bertjwregeer Feb 21, 2016

Member

I'd like to see the CSRF token stuff separated from the session, and become it's own stand-alone thing.

Member

bertjwregeer commented Feb 21, 2016

I'd like to see the CSRF token stuff separated from the session, and become it's own stand-alone thing.

@mmerickel

This comment has been minimized.

Show comment
Hide comment
@mmerickel

mmerickel Feb 21, 2016

Member

Sure! I think it'd be helpful to open a different issue and link to it from your idea where we can talk about that particular API if you'd like.

Member

mmerickel commented Feb 21, 2016

Sure! I think it'd be helpful to open a different issue and link to it from your idea where we can talk about that particular API if you'd like.

@bertjwregeer

This comment has been minimized.

Show comment
Hide comment
@bertjwregeer

bertjwregeer Mar 6, 2016

Member

Re-work @view_config and friends to possibly be multiple stacked decorators instead of sharing a single namespace so that it is easier to see what is a predicate versus what is used by the view machinery, or even view derivations.

Member

bertjwregeer commented Mar 6, 2016

Re-work @view_config and friends to possibly be multiple stacked decorators instead of sharing a single namespace so that it is easier to see what is a predicate versus what is used by the view machinery, or even view derivations.

@jvanasco

This comment has been minimized.

Show comment
Hide comment
@jvanasco

jvanasco Mar 25, 2016

Contributor

I'd like to be be able to access the currently expected "renderer" (and various other @view_config or add_view arguments) for the current request within the view's code. Currently, the only accessible data point within the view is the request.matched_route.name; and the template can get the current renderer... but that's all that I know of.

Contributor

jvanasco commented Mar 25, 2016

I'd like to be be able to access the currently expected "renderer" (and various other @view_config or add_view arguments) for the current request within the view's code. Currently, the only accessible data point within the view is the request.matched_route.name; and the template can get the current renderer... but that's all that I know of.

@mmerickel

This comment has been minimized.

Show comment
Hide comment
@mmerickel

mmerickel Mar 25, 2016

Member

@jvanasco These features are not a breaking change thus not on the roadmap for pyramid 2.0. In fact everything you requested will be available in 1.7 with the new view derivers feature.

Member

mmerickel commented Mar 25, 2016

@jvanasco These features are not a breaking change thus not on the roadmap for pyramid 2.0. In fact everything you requested will be available in 1.7 with the new view derivers feature.

@jvanasco

This comment has been minimized.

Show comment
Hide comment
@jvanasco

jvanasco Mar 25, 2016

Contributor

well that's pretty wonderful!

Contributor

jvanasco commented Mar 25, 2016

well that's pretty wonderful!

@ztane

This comment has been minimized.

Show comment
Hide comment
@ztane

ztane Jul 3, 2016

Contributor

I am currently testing how the auth-api postmortem works. However so far I've concluded that permits and authorized_userid perhaps shouldn't be in the same interface, but all in all, I'd really wish to see this change. Additionally, all the authz methods should have the request passed in.

Contributor

ztane commented Jul 3, 2016

I am currently testing how the auth-api postmortem works. However so far I've concluded that permits and authorized_userid perhaps shouldn't be in the same interface, but all in all, I'd really wish to see this change. Additionally, all the authz methods should have the request passed in.

@jvanasco

This comment has been minimized.

Show comment
Hide comment
@jvanasco

jvanasco Jul 11, 2016

Contributor

Have the ISession stop requiring an explicit call to 'changed()' for mutable objects by automatically detecting changes. [http://docs.pylonsproject.org/projects/pyramid/en/latest/api/interfaces.html#pyramid.interfaces.ISession.changed]

I did not realize Pyramid required this (or perhaps I forgot) and had some session manipulations that did not persist. This was awkward, as most other session systems do not require this.

I handled this in our fork of a session library by hashing the serialized version of a session on creation, and comparing that to a second fingerprint on cleanup [if the session did not otherwise have a reason to persist].

This sort of change would likely not break any apps, but it could likely break session libraries.

Contributor

jvanasco commented Jul 11, 2016

Have the ISession stop requiring an explicit call to 'changed()' for mutable objects by automatically detecting changes. [http://docs.pylonsproject.org/projects/pyramid/en/latest/api/interfaces.html#pyramid.interfaces.ISession.changed]

I did not realize Pyramid required this (or perhaps I forgot) and had some session manipulations that did not persist. This was awkward, as most other session systems do not require this.

I handled this in our fork of a session library by hashing the serialized version of a session on creation, and comparing that to a second fingerprint on cleanup [if the session did not otherwise have a reason to persist].

This sort of change would likely not break any apps, but it could likely break session libraries.

@mmerickel

This comment has been minimized.

Show comment
Hide comment
@mmerickel

mmerickel Jul 11, 2016

Member

Have the ISession stop requiring an explicit call to 'changed()' for mutable objects by automatically detecting changes.

What? This is up to the session whether this is required. Under normal scenarios it is only required if you perform a deep change on a mutable collection stored in the session, for obvious reasons.

The bundled session impl from pyramid does not require you to ever call changed unless you do what I described.

request.session['foo']['bar']['baz'] = 1
request.session.changed()
# versus
obj = copy.deepcopy(request.session['foo'])
obj['foo']['bar']['baz'] = 1
request.session['foo'] = obj
Member

mmerickel commented Jul 11, 2016

Have the ISession stop requiring an explicit call to 'changed()' for mutable objects by automatically detecting changes.

What? This is up to the session whether this is required. Under normal scenarios it is only required if you perform a deep change on a mutable collection stored in the session, for obvious reasons.

The bundled session impl from pyramid does not require you to ever call changed unless you do what I described.

request.session['foo']['bar']['baz'] = 1
request.session.changed()
# versus
obj = copy.deepcopy(request.session['foo'])
obj['foo']['bar']['baz'] = 1
request.session['foo'] = obj
@mmerickel

This comment has been minimized.

Show comment
Hide comment
@mmerickel

mmerickel Jul 11, 2016

Member

@jvanasco please open a specific issue instead of trying to talk about these things in the 2.0 feature list. It's really supposed to just be an aggregate of these various issues with their own discussion elsewhere.

Member

mmerickel commented Jul 11, 2016

@jvanasco please open a specific issue instead of trying to talk about these things in the 2.0 feature list. It's really supposed to just be an aggregate of these various issues with their own discussion elsewhere.

@ergo

This comment has been minimized.

Show comment
Hide comment
@ergo

ergo Jan 20, 2017

Member

I would love to see an asyncio support/integration out of the box if pyramid would be 3.5+ only - that would be a killer feature in my opinion.

Member

ergo commented Jan 20, 2017

I would love to see an asyncio support/integration out of the box if pyramid would be 3.5+ only - that would be a killer feature in my opinion.

@bertjwregeer

This comment has been minimized.

Show comment
Hide comment
@bertjwregeer

bertjwregeer Jan 20, 2017

Member

What does asyncio support/integration mean within the Pyramid framework? What integration are you looking for Pyramid to provide?

Member

bertjwregeer commented Jan 20, 2017

What does asyncio support/integration mean within the Pyramid framework? What integration are you looking for Pyramid to provide?

@ergo

This comment has been minimized.

Show comment
Hide comment
@ergo

ergo Jan 20, 2017

Member

I was thinking about core integration or package maintenance of something that would make sense that build on top of these projects where it makes sense:

https://pypi.python.org/pypi/aiopyramid
https://github.com/mardiros/pyramid_asyncio
https://github.com/etianen/aiohttp-wsgi

So far my personal experience includes using pyramid + gevent (which doesn't require anything special on pyramids end), but asyncio seems to be the next logical step here.

Member

ergo commented Jan 20, 2017

I was thinking about core integration or package maintenance of something that would make sense that build on top of these projects where it makes sense:

https://pypi.python.org/pypi/aiopyramid
https://github.com/mardiros/pyramid_asyncio
https://github.com/etianen/aiohttp-wsgi

So far my personal experience includes using pyramid + gevent (which doesn't require anything special on pyramids end), but asyncio seems to be the next logical step here.

@ergo

This comment has been minimized.

Show comment
Hide comment
@ergo

ergo Jan 20, 2017

Member

Another feature, incorporate @wichert s https://github.com/wichert/pyramid_authstack - its 40 something lines of code but i strongly believe this should be part of standard API.

Member

ergo commented Jan 20, 2017

Another feature, incorporate @wichert s https://github.com/wichert/pyramid_authstack - its 40 something lines of code but i strongly believe this should be part of standard API.

@rach

This comment has been minimized.

Show comment
Hide comment
@rach

rach Jan 22, 2017

Contributor

Allow to configure pserve (and others commands) via some hooks to make config_uri ( passing a file) not required. I think that's a frustration that will help some people to adopt pyramid. I know #2419 Try to improve the flexibility of this but it's really something that I would like to see improved in 2.0

Contributor

rach commented Jan 22, 2017

Allow to configure pserve (and others commands) via some hooks to make config_uri ( passing a file) not required. I think that's a frustration that will help some people to adopt pyramid. I know #2419 Try to improve the flexibility of this but it's really something that I would like to see improved in 2.0

@nek4life

This comment has been minimized.

Show comment
Hide comment
@nek4life

nek4life Apr 11, 2017

Contributor

One point of confusion I've had is the permission argument on view_config and the fact that it only accepts one permission. Suppose I have editor and moderator groups right now I think the solve for not adding more than one permission is to make a new group called editormoderator and use that instead. It seemed really counter intuitive to me to do so. Perhaps there is a good reason for this that I'm unaware of, but I wanted to bring it up for 2.0 if there is a chance to revisit this.

Contributor

nek4life commented Apr 11, 2017

One point of confusion I've had is the permission argument on view_config and the fact that it only accepts one permission. Suppose I have editor and moderator groups right now I think the solve for not adding more than one permission is to make a new group called editormoderator and use that instead. It seemed really counter intuitive to me to do so. Perhaps there is a good reason for this that I'm unaware of, but I wanted to bring it up for 2.0 if there is a chance to revisit this.

@bertjwregeer

This comment has been minimized.

Show comment
Hide comment
@bertjwregeer

bertjwregeer Apr 11, 2017

Member

@nek4life The permission should be "edit", and then on your context you have an acl that grants both the group:moderator and group:editor the permission edit.

For example:

class MyContext(object):
    __acl__ = [
        (Allow, 'group:moderators', 'edit'),
        (Allow, 'group:editors', 'edit'),
        (Allow, 'group:administrators', 'edit'),
    ]

Then your view_config would be:

@view_config(context=MyContext, permission='edit')
def myview(context, request):
    pass

And now anyone that has in their list of principals one of the following:

  • group:moderators
  • group:administrators
  • group:editors

Will have the edit permission.

Member

bertjwregeer commented Apr 11, 2017

@nek4life The permission should be "edit", and then on your context you have an acl that grants both the group:moderator and group:editor the permission edit.

For example:

class MyContext(object):
    __acl__ = [
        (Allow, 'group:moderators', 'edit'),
        (Allow, 'group:editors', 'edit'),
        (Allow, 'group:administrators', 'edit'),
    ]

Then your view_config would be:

@view_config(context=MyContext, permission='edit')
def myview(context, request):
    pass

And now anyone that has in their list of principals one of the following:

  • group:moderators
  • group:administrators
  • group:editors

Will have the edit permission.

@vanguard737

This comment has been minimized.

Show comment
Hide comment
@vanguard737

vanguard737 Apr 22, 2018

Late to the party here...The above link to the auth-api post-mortem has gone dead. (Which is a shame, since I've seen the same doc linked in a few SO responses.) Is this document available anyplace else?

vanguard737 commented Apr 22, 2018

Late to the party here...The above link to the auth-api post-mortem has gone dead. (Which is a shame, since I've seen the same doc linked in a few SO responses.) Is this document available anyplace else?

@merwok

This comment has been minimized.

Show comment
Hide comment
@ztane

This comment has been minimized.

Show comment
Hide comment
@ztane

ztane Apr 23, 2018

Contributor

I've said it elsewhere, the auth postmortem would make things much better, but the authz policy should really get a reference to the request too - now people write their own wrapper classes to contain the actual context classes just to pass the request implicitly into the authorization policy.

Contributor

ztane commented Apr 23, 2018

I've said it elsewhere, the auth postmortem would make things much better, but the authz policy should really get a reference to the request too - now people write their own wrapper classes to contain the actual context classes just to pass the request implicitly into the authorization policy.

@robinharms

This comment has been minimized.

Show comment
Hide comment
@robinharms

robinharms Apr 24, 2018

Hi all,
On that same note, auth does some funky stuff when checking roles ("groupfinder") during traversal in another tree.

Kotti solved this nicely:
https://github.com/Kotti/Kotti/blob/master/kotti/security.py

tl;dr: Consider a request in this structure:

/users/me
/users/someone_else

If I'm at 'me', request.context will be me.
If i check permission on something and i use request.has_permission('Edit', SomeOneElseObj) effective_principals will fetch principals from request.context and probably grant me something that isn't right :/

Passing along context to effective_principals might do the trick too?
What are your thoughts on this?

robinharms commented Apr 24, 2018

Hi all,
On that same note, auth does some funky stuff when checking roles ("groupfinder") during traversal in another tree.

Kotti solved this nicely:
https://github.com/Kotti/Kotti/blob/master/kotti/security.py

tl;dr: Consider a request in this structure:

/users/me
/users/someone_else

If I'm at 'me', request.context will be me.
If i check permission on something and i use request.has_permission('Edit', SomeOneElseObj) effective_principals will fetch principals from request.context and probably grant me something that isn't right :/

Passing along context to effective_principals might do the trick too?
What are your thoughts on this?

@mmerickel

This comment has been minimized.

Show comment
Hide comment
@mmerickel

mmerickel Apr 24, 2018

Member

@robinharms Please open a separate issue if you wish to discuss this. The intricacies of a particular issue don't belong in this roadmap thread. I will mention that the principals do not come from the context at all - only the request - and so something smells a little bit about your analysis so far.

Member

mmerickel commented Apr 24, 2018

@robinharms Please open a separate issue if you wish to discuss this. The intricacies of a particular issue don't belong in this roadmap thread. I will mention that the principals do not come from the context at all - only the request - and so something smells a little bit about your analysis so far.

@robinharms

This comment has been minimized.

Show comment
Hide comment
@robinharms

robinharms Apr 25, 2018

@mmerickel OK I'll do that. Regarding principals, that's exactly the problem :)

robinharms commented Apr 25, 2018

@mmerickel OK I'll do that. Regarding principals, that's exactly the problem :)

@stevepiercy

This comment has been minimized.

Show comment
Hide comment
@stevepiercy

stevepiercy Apr 26, 2018

Member

Two items for documentation consideration:

  • Support poetry, flit, pipenv (whatever) in our documentation #3270
  • Keep install and setup instructions for Unix and Windows, but remove Windows commands from all other places in the documentation, per #3260 (comment)
Member

stevepiercy commented Apr 26, 2018

Two items for documentation consideration:

  • Support poetry, flit, pipenv (whatever) in our documentation #3270
  • Keep install and setup instructions for Unix and Windows, but remove Windows commands from all other places in the documentation, per #3260 (comment)
@mcdonc

This comment has been minimized.

Show comment
Hide comment
@mcdonc

mcdonc Jul 3, 2018

Member

I'd be willing to make a call on what to do about #2607 (make append_slash_notfound_view use a subrequest) and to do the work that falls out for 2.0.

Member

mcdonc commented Jul 3, 2018

I'd be willing to make a call on what to do about #2607 (make append_slash_notfound_view use a subrequest) and to do the work that falls out for 2.0.

@stevepiercy

This comment has been minimized.

Show comment
Hide comment
@stevepiercy

stevepiercy Jul 15, 2018

Member

A couple more to the list above:

  • Add Python 3.7 support #3312
  • Add Python 3.8 if released, at least in Travis/Appveyor
Member

stevepiercy commented Jul 15, 2018

A couple more to the list above:

  • Add Python 3.7 support #3312
  • Add Python 3.8 if released, at least in Travis/Appveyor
@ergo

This comment has been minimized.

Show comment
Hide comment
@ergo

ergo Sep 20, 2018

Member

I was thinking that first class out-of-the-box mixing sync and async requests from separate thread would be a killer feature for pyramid 2.x.

Member

ergo commented Sep 20, 2018

I was thinking that first class out-of-the-box mixing sync and async requests from separate thread would be a killer feature for pyramid 2.x.

@wichert

This comment has been minimized.

Show comment
Hide comment
@wichert

wichert Sep 20, 2018

Member
Member

wichert commented Sep 20, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment