Excerpts from Morgan Fainberg's message of 2015-08-04 06:05:56 +1000: > > > On Aug 4, 2015, at 05:49, Doug Hellmann <d...@doughellmann.com> wrote: > > > > Excerpts from Sergey Vilgelm's message of 2015-08-03 22:11:50 +0300: > >>> On Mon, Aug 3, 2015 at 9:37 PM, Doug Hellmann <d...@doughellmann.com> > >>> wrote: > >>> > >>> Making that function public may be the most expedient fix, but the > >>> parser was made private for a reason, so before we expose it we > >>> should understand why, and if there are alternatives (such as > >>> creating a fixture in oslo.policy to do what the nova tests need). > >> > >> Probably we may extend the Rules class and add the similar functions as a > >> classmethod? > >> I've created a patch for slo.policy as example[1] > > > > Well, my point was that the folks working on that library considered the > > entire parser to be private. That could just be overly ambitious API > > pruning, or there could be some underlying reason (like, the syntax may > > be changing or we want apps to interact with APIs and not generate DSL > > and feed it to the library). So we should find out about the reason > > before looking for alternative places to expose the parser. > > > > The idea is to have apis vs dsl generation. But we did a "everything private > that isnt clearly used" as a starting point. I would prefer to not make this > public and have a fixture instead. That said, i am not hard-set against a > change to make it public.
It would be easy enough to provide a fixture, which would make it clear that the API is meant for testing and not for general use. I see a couple of options: 1. a fixture that takes some DSL text and creates a new Enforcer instance populated with the rules based on parsing the text 2. a fixture that takes some DSL text *and* an existing Enforcer instance and replaces the rules inside that Enforcer instance with the rules represented by the DSL text Option 1 feels a little cleaner but option 2 is more like how Nova is using parse_rule() now and may be easier to drop in. Doug > > > Doug > > > >> > >> [1] https://review.openstack.org/#/c/208617/ > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev