Closed yasushi-saito closed 5 years ago
Sorry for the slow response.
Yes, gojupyterscaffold
is designed for general Jupyter kernels in Go and I'm happy if it's used from other kernels. To use the library from other kernels, I also think we should reduce unnecessary dependencies from gojupyterscaffold
.
Or at least have some indirection mechanism so that they don't need to hardcode dependencies on glog?
I got used to glog
and I want to keep using it in my kernel. Thus, I will remove the direct dependency from gojupyterscaffold
to glog
by introducing indirection mechanism. Sounds good?
Sounds good. Thanks.
On Sat, Feb 16, 2019, 1:58 AM Yu Watanabe notifications@github.com wrote:
Sorry for the slow response.
Yes, gojupyterscaffold is designed for general Jupyter kernels in Go and I'm happy if it's used from other kernels. To use the library from other kernels, I also think we should reduce unnecessary dependencies from gojupyterscaffold.
Or at least have some indirection mechanism so that they don't need to hardcode dependencies on glog?
I got used to glog and I want to keep using it in my kernel. Thus, I will remove the direct dependency from gojupyterscaffold to glog by introducing indirection mechanism. Sounds good?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/yunabe/lgo/issues/74#issuecomment-464328601, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhVs3lNHTtwT16zCzbHGrjgNYq1ecg_ks5vN9ZdgaJpZM4ahtam .
I've been trying to use gojupyterscaffold to write a new kernel (not Go), but I found that it uses glog, which defines its own set of flags, e.g., log_dir and logtostderr, which conflicts with other logging modules we are using. Is it possible to stop using glog in lgo's library packages and instead use the standard log? Or at least have some indirection mechanism so that they don't need to hardcode dependencies on glog?