Which UX do you prefer for a target with a `file_m...
# development
Which UX do you prefer for a target with a
field (for file permissions/mode)? • int:
• str:
• object:
file_mode=perm(u=6, g=4, o=4)
• Something else? Ultimately this will end up represented as an octal in yaml, when passing it to the underlying app.
The only obviously off suggestion is object. If you're going to offer that, you probably should be making the argument values "rwx", "r-x", etc. Seems almost mean to offer up things like u= ... and then force a number.
Basically a very mixed metaphor. you never use in unix.
That's fair. I don't think I would like the object option either. I'm trying to think of something that lends itself to validating the input. I wish there was a way to enforce octal input as int is easy to accidentally pass the wrong thing. But oct and int are essentially equivalent in python.
Why validate? I think Pants often tries to do to much. The OS will validate.
What if they really do run pants as root for a reason and want to set the sticky bit?
There are a lot of technically valid things you can do with mode that are almost never intended.
Sounds like nanny. You may be right for 10 users and piss off the 11th that knows what they are doing
You leave them no out except to table flip Pants and maybe walk away.
I just urge a ton of caution on validation.
Yeah. I don't want to write something complex. Ideally there would be an octal type where if I pass an integer in the BUILD file it could warn me.
Ok, well that obviously goes beyond what Python itself thinks is smart to do in their own APIs...
What about: • expose what the raw tool consumes (int/octal) • potentially provide helpers to generate the common types of that (e.g. a
permissions(u="rwx", ...)
function, or something), maybe as separate work
The field itself may accept both string and int and normalize during
. If you promote string, with a syntax of
for instance, that’s easy to read and write for a human while also offering to go int/octal for superusers. Validation on the
value while accepting any int value. I agree with John, that validation ought not to be too restricting, only catching things that are absolute errors. Also -1 on object, I think. (could be a factory method added later if desired as Huon suggested, so the field still consumes str/int only)
👍 1
Octal seems idiomatic to me