Not an issue, but a nice way to use local modules in the notebook

[oderwat]

I started to use gonb to develop and write examples for some modules of a framework that we are developing and found that quite helpful and elegant.

I use "go.work" files while adding features over multiple modules and packages. When using go mod edit you need to add package names and absolute paths. I prefer using go.work files and found a way to add them to the "gonb" notebook, that I find particular nice and wanted to share. It uses the directory names and the current user is evaluated.

!* rm -f go.work && go work init && go work use . "/home/$(id -un)/workspace/localmod"

[janpfeifer]

hey @oderwat , thanks for letting me know, let me incorporate that into the tutorial!

Something I was curious about was whether that was working with gopls. Meaning if changes in the files you are editing get parsed and auto-completed in GoNB ?

I tried it, by including it in the list of files "notified" to gopls (see goexec/inpsect.go#L22 and goexec/tracking.go#L241), but I never really tested it.

cheers

[oderwat]

This is a good question. When I use the notebook without docker on my mac, it currently does not work with the language server at all. I did not look into that so far:

[W 16:20:57.048 NotebookApp] Error loading server extension jupyter_lsp
    Traceback (most recent call last):
      File "/usr/local/Cellar/jupyterlab/4.0.2/libexec/lib/python3.11/site-packages/notebook/notebookapp.py", line 2050, in init_server_extensions
        func(self)
      File "/usr/local/Cellar/jupyterlab/4.0.2/libexec/lib/python3.11/site-packages/jupyter_lsp/serverextension.py", line 76, in load_jupyter_server_extension
        nbapp.io_loop.call_later(0, initialize, nbapp, virtual_documents_uri)
        ^^^^^^^^^^^^^
    AttributeError: 'NotebookApp' object has no attribute 'io_loop'

So, I was not having "gopls" support at all. I can't really (easily) use the docker because many of the modules are from private repositories and I would need to add that setup to either the docker image or the notebook.

I am actually using it for some bug fixing and redesigning an API so I had no time to check what is wrong with gopls. I am also new to jupyter notebooks (just used some occasionally in the past).

[janpfeifer]

Sadly I don't have an easily available Mac to try it out and fix it ... But the error message sounds odd, since it should be GoNB talking to the language server, not Jupyter. I wonder if something is different in the Jupyter installation in Mac, that it's not using GoNB for auto-complete (or contextual help).

Do you want to open a separate issue for that ? Maybe someone with a Mac could find it out ? If someone tells me what is wrong I'd happily fix it.

Just in case: the docker (in Linux at least) can be executed sharing arbitrary directories with the host (it's just an extra flag). So actually using the docker and private repositories (I've used that before) in the host could work -- but I don't know the details, and it's also possible it wouldn't for other reasons.

[oderwat]

I was using the docker variant to access the other directories, the problem is more that the repositories are private and the go installation inside the docker image cannot access them without some changes to git and docker configs (go mod download fails). We made some other images for our CI chains that can can handle this by setting up the docker so that it has access.

[quickwritereader]

@janpfeifer is there a better way to reuse the shell variable? or is there a better way to switch to gonb temporary folder within shell instead of !*
I have to write to the temp file

!echo ${PWD} >/tmp/curr_dir
!*CURR_DIR=`cat /tmp/curr_dir` && rm -f go.work && go work init && go work use . "${CURR_DIR}/mymodule"
%goworkfix

[janpfeifer]

hi @quickwritereader , sorry I was away these last couple of days.

Currently you can use the %env special command to set an environment variable in the kernel space (so it will be passed to all shell executions and well as Go cell executions):

%env CURR_DIR /home/user/work 

But it requires some copy&pasting of the current directory.

What I could do, if it's helpful, and to automatically create an environment variable with the current directory (different than the temp folder). Let me know if it helps -- and maybe create a new issue to track it. It's a trivial change, and likely can be done by tomorrow.

[janpfeifer]

I did the small change to expose two environment variables: GONB_DIR and GONB_TMP_DIR, in a branch called dirs, see https://github.com/janpfeifer/gonb/tree/dirs

A sample of the output would be:

!echo "From current dir:" && pwd && echo "GONB_DIR=$GONB_DIR" && echo "GONB_TMP_DIR=$GONB_TMP_DIR" && echo
!*echo "From temporary Go dir:" && pwd && echo "GONB_DIR=$GONB_DIR" && echo "GONB_TMP_DIR=$GONB_TMP_DIR" && echo

The output is:

From current dir:
/opt/janpf/work
GONB_DIR=/opt/janpf/work
GONB_TMP_DIR=/tmp/gonb_e6352989

From temporary Go dir:
/tmp/gonb_e6352989
GONB_DIR=/opt/janpf/work
GONB_TMP_DIR=/tmp/gonb_e6352989

Let me know if this works. In any case tomorrow or Monday I'll create a new release including it.

Or if you have any other suggestions (including the variable names...)

thanks for the report!

[oderwat]

I like it ;-)

[janpfeifer]

v0.7.5 released with the changes. Also a new docker.

[oderwat]

I have yet another problem, but let's close this for good now.