Conditions DEP
171 views
Skip to first unread message
Connor Boyle
Jun 5, 2016, 10:52:57 PM6/5/16
to Django developers (Contributions to Django itself)
I'd like to make a proposal for the addition of a major new feature to Django. Back in late March of this year, I wrote an original Google Summer of Code proposal that received some interest from several members of the community, but neither I nor this proposal were selected for GSoC. A community member (iirc it was Florian Apolloner) told me to put the proposal in the form of a DEP.
For those not previously introduced (or who need a reminder), this proposal is for a standardized system of "conditions"–dynamic rules written in plain Python–which would be used primarily to evaluate whether an action (in most cases, the execution of a view) should be allowed. Comparable features include Django-Rules and the permissions system in Django Rest Framework.
The current version of the DEP is attached here. I am currently seeking at least a shepherd and hopefully other implementors. Any and all thoughtful critique would be highly appreciated.
Thanks,
Connor
Tim Allen
Jun 6, 2016, 9:29:48 AM6/6/16
to Django developers (Contributions to Django itself)
Hi Connor,
How would you prefer suggested tweaks to your proposal? Since it is on GitHub, would you prefer pull requests? Thank you for taking the initiative!
Regards,
Tim
Carl Meyer
Jun 6, 2016, 12:34:45 PM6/6/16
to django-d...@googlegroups.com
Hi Connor,
On 06/05/2016 07:52 PM, Connor Boyle wrote:
> I'd like to make a proposal for the addition of a major new feature to
> Django. Back in late March of this year, I wrote an original Google
> Summer of Code proposal
> <https://gist.github.com/cascadianblue/2856bea128dd1b3f4d0f> that
anything in the proposal that inherently needs to be part of Django core
in order to be useful; it seems that it could just as well be
implemented as an installable library. When there's a new feature idea
that _can_ live external to Django core, we generally prefer that it
_does_ live external to core, at least for a while to prove the design
and demonstrate its practical advantage over similar alternatives.
Living outside core allows you to iterate much more rapidly on the
design, with new releases as often as you need them.
If in the future it becomes the clear winning implementation of a
pattern that is important enough that it should be available to all
Django users by default, we may decide to bring it into core.
Note that this isn't just a theory or something we tell people, it's
something that actually happens regularly, including with proposals from
core team members. See for example South, django-security,
django-transaction-hooks, django-channels...
So my recommendation is that you implement your proposal as a
pip-installable library and advertise it, see whether it gains traction
that way, and see what you learn about the design from having it
exercised by real users.
Carl
On 06/05/2016 07:52 PM, Connor Boyle wrote:
> I'd like to make a proposal for the addition of a major new feature to
> Django. Back in late March of this year, I wrote an original Google
> Summer of Code proposal
> received some interest from several members of the community, but
> neither I nor this proposal were selected for GSoC. A community member
> (iirc it was Florian Apolloner) told me to put the proposal in the form
> of a DEP.
I read through the DEP - it's an interesting idea. I'm not seeing
> neither I nor this proposal were selected for GSoC. A community member
> (iirc it was Florian Apolloner) told me to put the proposal in the form
> of a DEP.
anything in the proposal that inherently needs to be part of Django core
in order to be useful; it seems that it could just as well be
implemented as an installable library. When there's a new feature idea
that _can_ live external to Django core, we generally prefer that it
_does_ live external to core, at least for a while to prove the design
and demonstrate its practical advantage over similar alternatives.
Living outside core allows you to iterate much more rapidly on the
design, with new releases as often as you need them.
If in the future it becomes the clear winning implementation of a
pattern that is important enough that it should be available to all
Django users by default, we may decide to bring it into core.
Note that this isn't just a theory or something we tell people, it's
something that actually happens regularly, including with proposals from
core team members. See for example South, django-security,
django-transaction-hooks, django-channels...
So my recommendation is that you implement your proposal as a
pip-installable library and advertise it, see whether it gains traction
that way, and see what you learn about the design from having it
exercised by real users.
Carl
Connor Boyle
Jun 6, 2016, 3:43:57 PM6/6/16
to Django developers (Contributions to Django itself)
Thanks Tim,
Posting directly on this thread (with quotes of relevant sections of the proposal) I think would also work fine.
Connor Boyle
Jun 6, 2016, 4:25:16 PM6/6/16
to Django developers (Contributions to Django itself)
Hi Carl,
Thanks,
Connor
Carl Meyer
Jun 6, 2016, 4:42:50 PM6/6/16
to django-d...@googlegroups.com
Hi Connor,
On 06/06/2016 02:25 PM, Connor Boyle wrote:
> Should I stop working on the DEP then?
That's up to you, if it's useful to you as a design document. Obviously
there's no need for a DEP for you to release your own project. If the
project is a success and later becomes a candidate for inclusion in
core, the DEP might be useful then (but would likely need updating to
reflect experience gained and design changes in the meantime).
> Also, would it be at all
> appropriate to continue using this mailing list (for say, updates on the
> project and requests for review)?
Until you're at a point where you're ready to request consideration of
your project for inclusion in core, probably django-users would be a
better venue (also one with a much bigger audience!) Unless of course
you run into limitations of Django that prevent you from implementing
some part of your concept externally, then discussion of addressing that
limitation would certainly belong here.
Carl
On 06/06/2016 02:25 PM, Connor Boyle wrote:
> Should I stop working on the DEP then?
there's no need for a DEP for you to release your own project. If the
project is a success and later becomes a candidate for inclusion in
core, the DEP might be useful then (but would likely need updating to
reflect experience gained and design changes in the meantime).
> Also, would it be at all
> appropriate to continue using this mailing list (for say, updates on the
> project and requests for review)?
your project for inclusion in core, probably django-users would be a
better venue (also one with a much bigger audience!) Unless of course
you run into limitations of Django that prevent you from implementing
some part of your concept externally, then discussion of addressing that
limitation would certainly belong here.
Carl
Reply all
Reply to author
Forward
0 new messages