Rules 2.0 about django-rules

[bpereto]

2.0.0 is released 🎉
So we can close this?

[bulv1ne]

Would it be useful to create a milestone/project in github to decide what needs to be done for rules-2.0? I'd gladly help but I don't really know where to begin.

rules still supports older unsupported versions of django that maybe can be removed/cleaned up? #52 tries to fix this but is now over 1 year old.

[azreda]

Hi @dfunckt I think the rules naming is causing unnecessary confusion, causing issues like #49 and #53 I think this app will be better served by resolving this naming conflict, perhaps by changing the autodiscovered module name to something else.

[dfunckt]

@azreda naming of things in rules has been a disaster -- just consider the confusion stemming from the different name of the project on Github and Pypi.

Any idea on what to name the module? I can't really think of a new module name that is appropriate. I guess permissions.py is a nice candidate but it has two problems itself:

1. it suggests rules is solely for permissions
2. it's possible it will conflict with other apps

On the other hand, Python 3 slowly becomes a lot more widespread and this issue will fade in the background in time, so it may not worth to change the name anymore.

I'm really open to ideas however, it would be great to sort it out once and for all if we can come up with an appropriate module name.

[azreda]

@dfunckt I have been using perms.py in my projects, and auto discovering those modules. This avoids other common uses of premissions.py by other projects, including django rest framework. That said, something real different like djrules.py or django_rules.py might settle this even more clearly.

[jberends]

• or call it rulesets.py we use to differentiate the confusion with permissions.py. Our best practise is to use to import the rulesets in the AppConfig.ready() function of each app.
• another thing is python3.6 compatibility, which needs refactoring of the Predicates class (see #57); but II guess that is also covered by implementing #32

[JakobGM]

I think rulesets.py is probably one of the better proposed names here, although I am more inclined to believe that Python 3 adoption slowly solves this issue for us.

Personally, I am most interested in type annotations becoming supported in 2.0.

Looking forward to the 2.0 release,
Thanks for the great work!

[shacker]

I'm having trouble explaining the difference between rules and permissions to our developers, because I'm a little fuzzy on it myself. Reading and re-reading the documentation, it's not clear to us what the difference between them is, or how to decide when to use one or the other.

Rules and permissions are created the same way but with either rules.add_rule or rules.add_perm. How should a developer decide when to write and use one or the other? Both can be checked for in templates, but with different invocations. Only perms can be checked for on view decorators (@permission_required). Devs keep writing rules but then checking in templates with has_perm and vice versa. I'd like to be able to say "use perms when you need to check permission to access a particular object rather than, say, to check a user's group membership," but that's not true either - we have plenty of perms (not rules) that aren't about a particular object.

Why are there two separate "layers" to the system? If there is a clear and useful distinction, can you document the difference explicitly? If not, my somewhat radical suggestion for 2.0 would be to collapse the two sets into one. Either keep rules or perms, but not both - they both seem to do the same job. For backwards compatibility, you could continue to support the invocation syntax of the discarded set. I think this could be a really nice improvement for 2.0.

Thanks for considering.

[dfunckt]

@shacker sorry for the late reply, I somehow missed your comment.

Permissions are a specialisation of rules that plug into Django's permission system. Typically you'd use permissions if you're using Django and you want to hide the fact you're actually using rules (the package) to implement permissions, i.e. you're doing user.has_perm().

Rules are more general, do not assume Django exists, need no setup, and can be used to abstract away anything you would otherwise write in an if statement. They're merely a convenience. To access them you must use the API rules exposes, i.e. rules.test_rule().

There's yet another layer you can work on, that's even more generic, and that's custom RuleSets. Permissions use a global ruleset dedicated to permissions, rules use another ruleset dedicated to them, but you can create arbitrary numbers of rulesets yourself to compartmentalise logic. You then import that ruleset in your code and use the API provided by RuleSet, i.e. ruleset.test_rule(), etc. A typical example of custom rulesets is to implement feature flags, see the README for how that could look like.

[shacker]

@dfunckt Thanks for the explainer. So since django-rules needs to support both django and non-django projects, rules and permissions are never going to be collapsed into a single function.

Would it be fair to say "If you are working on a Django project, keep things clear and consistent by defining permissions only - you shouldn't need both rules and permissions."

It would be really helpful to add your first two paragraphs above, and possibly my sentence there, to the documentation.

[dfunckt]

Indeed!