https://pantsbuild.org/ logo
Join Slack
Powered by
It feels like we’ve gotten to a point where passin...
# development
a
It feels like we’ve gotten to a point where passing options across the ffi boundary is getting onerous. 
scheduler_create
now takes 50 arguments, which is not great. Some of these don’t express the expressiveness of their types in either language (e.g. we’re representing “no value” for strings as the empty string) There’s a bunch of boilerplate associated with passing them down They’re generally all global args, ungrouped by something like a subsystem, and most of which restart the daemon, only because we happen to use them when constructing the 
Core
(where some of them could be better scoped and exist on 
Session
- that’s an easy change for us to make if we want, though) Does anyone have any thoughts on how we could rationalise this a bit?
👍 2
w
could switch to passing in an "options" struct of some sort, and then using externs to grab the fields
... probably all immediately beyond the FFI boundary though, to keep it contained
e
jsonify?
then serdifyed structs on the rust side
h
I've thought about this myself
I'm not entirely sure what to do to fix it
I think it's possible that we could take an initial stab at cleaning this up by using some rust-side macros to reduce the total amount of code involved with passing type and type constructor handles around
all the 
construct_
arguments, as far as I can tell, are created on the python side the same way as 
type_
arguments - you pass the same class name and treat it either as a constructor function or as the name of a type
so maybe consolidating those could reduce the total amount of arguments passed to 
scheduler_create
e
To give a fuller justfucation for a serialized form for passing config - eventually we want client / server, probably both rust so that we have a truly snappy CLI that talks to a long-lived daemon that collects - at least - fs change state as it happens like we do today,
w
@enough-analyst-54434: i think that the plan so far has been to double down on nailgun for that.
so the client doesn't need to send things to the server other than args/env/etc.
e
OK - that makes more sense.
w
which is what pantsd does... except that the client is python
i like the serde+json idea, but it might make it challenging to pass more complicated stuff.
the advantage to using externs on a 
Value
passed over is that it aligns with how we do our other python object interaction
so by improving it, we improve all interaction from rust -> python objects
e
If config is more complicated than we currently have - which is all jsonifiable, that's surprising
w
yea, maybe.
h
either way, it's a bit awkward that 
create_scheduler
has a bunch of arguments that are passing type handles around, and also a bunch of other arguments for passing options around
w
sidenote: my work for today is adding client support to https://github.com/stuhood/nails so that we can look at using it in the engine's interaction with nailgun servers (in https://github.com/pantsbuild/pants/pull/8371)
h
that seems like not the right separation of concerns
w
@hundreds-breakfast-49010: yea, see the first reply in the thread
h
yeah some kind of options struct seems like a good idea to me
w
dataclass, i guess i should have said
h
Open in Slack
PreviousNext
Powered by