It feels like we’ve gotten to a point where passin...
# development
It feels like we’ve gotten to a point where passing options across the ffi boundary is getting onerous.
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
(where some of them could be better scoped and exist on
- 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
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
then serdifyed structs on the rust side
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
arguments, as far as I can tell, are created on the python side the same way as
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
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,
@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.
OK - that makes more sense.
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
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
If config is more complicated than we currently have - which is all jsonifiable, that's surprising
yea, maybe.
either way, it's a bit awkward that
has a bunch of arguments that are passing type handles around, and also a bunch of other arguments for passing options around
sidenote: my work for today is adding client support to so that we can look at using it in the engine's interaction with nailgun servers (in
that seems like not the right separation of concerns
@hundreds-breakfast-49010: yea, see the first reply in the thread
yeah some kind of options struct seems like a good idea to me
dataclass, i guess i should have said