These are chat archives for dry-rb/chat

22nd
Jan 2018
Drew Olson
@drewolson
Jan 22 2018 21:03
hey all. i'm trying to use dry-system with protobuf generated classes. i've added the directory with the protobuf generated files to load_paths but i don't seem to be able to inherit from those classes.
in this case i need to have access to the class constant to be able to inherit from that class
this isn't an injected dependency, but also it doesn't seem to automatically load this from the load path
Drew Olson
@drewolson
Jan 22 2018 21:17
generally, does dry-system force you to manually require any files that contain superclasses to your current class?
Tim Riley
@timriley
Jan 22 2018 21:17
@drewolson dry-system stays out of that
(unless they’re somehow required by auto-registration)
But apart from that you need to explicitly require the files you need for your app to work.
Drew Olson
@drewolson
Jan 22 2018 21:18
ok, so i do have to manually require these files, got it.
Tim Riley
@timriley
Jan 22 2018 21:18
yep
Drew Olson
@drewolson
Jan 22 2018 21:18
grpc generates stubs that i have to inherit from
can things inside of boot depend on things outside of boot?
Tim Riley
@timriley
Jan 22 2018 21:23
what do you mean by this, specifically?
Drew Olson
@drewolson
Jan 22 2018 21:24
to create a grpc server, i need to pass it any number of service instances to the handle function. i'd like to do this in the boot callback for the grpc_server that i've added to the container.
these service instances are classes that are auto registered
i get an error if i try to have my boot callback rely on one of these autoregistered classes, it seems
Tim Riley
@timriley
Jan 22 2018 21:28
yeah, bootable components are booted before auto-registration, so this’d be why
Drew Olson
@drewolson
Jan 22 2018 21:28
ah, bummer.
Tim Riley
@timriley
Jan 22 2018 21:28
you could require/register them manually, though
within the bootable component
Drew Olson
@drewolson
Jan 22 2018 21:29
i have another way around this, by wrapping the actually registering of these services and running the grpc sever in another auto-registered classes
Tim Riley
@timriley
Jan 22 2018 21:32
Ah OK
Drew Olson
@drewolson
Jan 22 2018 21:32
how does the container use the name you configure it with?
Tim Riley
@timriley
Jan 22 2018 21:32
Sorry, I don’t really know grpc, so I can’t really advise on specifics
Drew Olson
@drewolson
Jan 22 2018 21:32
no problem, thanks, i'm past my issue.
Tim Riley
@timriley
Jan 22 2018 21:32
Right now it doesn’t really use name for much. But it’ll be handy once we add more instrumentation/logging.
just to identify the container
Drew Olson
@drewolson
Jan 22 2018 21:33
got it, thanks
Drew Olson
@drewolson
Jan 22 2018 21:49
is there a way to memoize injection of classes that are auto-registered?
Tim Riley
@timriley
Jan 22 2018 21:50
@drewolson i.e. to make it a real singleton?
Drew Olson
@drewolson
Jan 22 2018 21:50
yes
similar to guice's @Singleton annotation
Tim Riley
@timriley
Jan 22 2018 21:51
We don’t have any such feature at the moment but I could see it being nice
Drew Olson
@drewolson
Jan 22 2018 21:51
it is very useful in guice
Tim Riley
@timriley
Jan 22 2018 21:51
However, you can write your own code to manually adjust container item resolution
so you could do it manually if you wanted
also, if the object is an actual singleton (i.e. if it responds to .instance and not .new) then dry-system will handle that accordingly
Drew Olson
@drewolson
Jan 22 2018 21:53
interesting. is there an example of that somewhere?
Drew Olson
@drewolson
Jan 22 2018 21:56
@timriley can you still use the injector in a singleton?
Tim Riley
@timriley
Jan 22 2018 22:08
Hmm, I would say no, dry-auto_inject is built to generate .new and #initialize methods
Drew Olson
@drewolson
Jan 22 2018 23:04
@timriley local testing tells me that auto_inject does seem to work with Singleton
which is pretty awesome
Piotr Solnica
@solnic
Jan 22 2018 23:05
@drewolson dry-system has a Singleton-aware loader
Drew Olson
@drewolson
Jan 22 2018 23:05
@solnic very cool, thanks!
Drew Olson
@drewolson
Jan 22 2018 23:06
@solnic is it idiomatic within a dry-system app to directly require any dependencies that are not injected? e.g. classes you inherit from or stdlib capabilities that you need?
Piotr Solnica
@solnic
Jan 22 2018 23:06
@drewolson yes, we follow the "require what your require" rule
Drew Olson
@drewolson
Jan 22 2018 23:06
(i'm a long time ruby dev but i've been working with java / guice for the past few years so this is all suddenly very interesting to me)
Piotr Solnica
@solnic
Jan 22 2018 23:07
basically, ANY part of your app should be require-able as a standalone piece
Drew Olson
@drewolson
Jan 22 2018 23:07
should every class require the container?
the example apps seem to assume it is already available
Piotr Solnica
@solnic
Jan 22 2018 23:07
the container is your entry-point, but then you should be able to do require "app/my_thing" and it should work
Drew Olson
@drewolson
Jan 22 2018 23:07
yeah, ok
so you assume the container is there, right?
because you always enter through it
Piotr Solnica
@solnic
Jan 22 2018 23:07
typically you require your import module
Drew Olson
@drewolson
Jan 22 2018 23:08
ah, yes, i'm just inlining import App.injector[]
Piotr Solnica
@solnic
Jan 22 2018 23:08
ie require "my_app/import" and that thing pulls in the container
Drew Olson
@drewolson
Jan 22 2018 23:08
which works fine for me
i'm still not totally clear on the difference between boot and "normal" capabilities
but it seems like boot time allows you to defer requiring gems until they are actually used?
Piotr Solnica
@solnic
Jan 22 2018 23:11
booting is for heavy stuff, especially if you want to have multiple stages of setting something up
Piotr Solnica
@solnic
Jan 22 2018 23:17

ah, yes, i'm just inlining import App.injector[]

this creates a new import module all over again, so it'd be better to define it once, in a file that requires container

Drew Olson
@drewolson
Jan 22 2018 23:17
@solnic got it, thanks
should the injector be in system or lib?
or does it not matter?
Piotr Solnica
@solnic
Jan 22 2018 23:18
in dry-web apps we put it under system
Drew Olson
@drewolson
Jan 22 2018 23:18
great, thanks for your help
Piotr Solnica
@solnic
Jan 22 2018 23:19
ie #{root}/system/your_app_namespace/import.rb
system is just the default name for config.system_dir, you can call it whatever you like
Drew Olson
@drewolson
Jan 22 2018 23:20
oh, very interesting. that's nice, i could bundle it inside lib if i prefer?
Piotr Solnica
@solnic
Jan 22 2018 23:25
whatever feels right in your case
we put it under system because lib is reserved for app’s APIs, and this is more of a configuration part