I noticed a few things that seem out of place in lib389’s cli tools. I just want to point out that using raw print isn’t really correct. Using log allows us to capture the written output for test verification, so always use log, not print.
If you are then writing a function on a lib389 dsldapobject, you shouldn’t directly log the output either. You should return it (probably as a dict!) to the caller. This way the caller can either display/format the object correctly *or* they can consume the data in further functions. Even more important, by simply returning a dict, you can consume the _json magic. I saw an example where get_attr_vals was used, and then ensure_str called, then json transformed. The better way would have been to use get_attr_vals_utf8_json() which would have done all the correct wrapping and transformation for you :)
I know it seems nitpicky, but little details like this matter for testing and api cleanliness and reuse in future applications :)
Software Engineer, 389 Directory Server
I’ve been speaking to Anuj Borah about a PR they made, and how we can properly represent nsRole.
because nsRoles are an extra objectClass, rather than a standalone one, we need a way to represent this properly.
It’s probably a good idea to use some of pythons composability here, where we could do something like:
class User_nsFilteredRole(User, nsFilteredRole):
Then to have a way to define and have each subclass called, and asserted for correctness. A question is how we would handle:
user = User.create(…)
# How to convert user to User_nsFilteredRole
We could do something like:
And have a from that does a valid conversion based on types and adds in the required role parts?
This isn’t a common scenario, so I think having a limited set of well understood types that require this type of conversion would be okay.
Thought? *looking at you Simon* :)
PS: It’s good to be back