Which UX do you prefer for a target with a

file_mode

field (for file permissions/mode)? • int:

file_mode=0o644

• str:

file_mode="644"

• 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.

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.

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

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

compute_value

. If you promote string, with a syntax of

"r-xr-xrwx"

for instance, that’s easy to read and write for a human while also offering to go int/octal for superusers. Validation on the

str

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)

Octal seems idiomatic to me