feature request: support gonb

[HaveF]

Thanks for this repo!

could it possible support gonb?

for now, error:

jupytext.formats.JupytextFormatError: Extension '.go' is not a notebook extension. Please use one of '.ipynb', '.md', '.markdown', '.Rmd', '.py', '.coco', '.R', '.r', '.jl', '.cpp', '.ss', '.clj', '.scm', '.sh', '.ps1', '.q', '.m', '.wolfram', '.pro', '.js', '.ts', '.scala', '.rs', '.robot', '.resource', '.cs', '.fsx', '.fs', '.sos', '.java', '.groovy', '.sage', '.ml', '.hs', '.tcl', '.mac', '.gp', '.do', '.sas', '.xsh', '.qmd', '.myst', '.mystnb', '.mnb', '.auto'.

[mwouts]

Hi @HaveF , thanks for reaching out! Yep sure it would be a great addition.

For that I would need at least a short example notebook, or ideally a full pull request. The process for adding a new language is documented here: https://jupytext.readthedocs.io/en/latest/contributing.html#add-support-for-another-language.

Thanks!

[HaveF]

@mwouts Thanks for the reference!
The process for adding a new language seems easy, let me try it!

[HaveF]

I believe I can't fix it by myself. @mwouts

added _SCRIPT_EXTENSIONS in jupytext/languages.py:

    ".go": {"language": "go", "comment": "//"},

simple hello_world_gonb.ipynb, I have zipped it for upload to this issue.

hello_world_gonb.ipynb.zip

some error:

E                       jupytext.compare.NotebookDifference: Cell content differ on code cell #4:
E                       --- expected
E                       +++ actual
E                       @@ -1,2 +1 @@
E                       -%%
E                        fmt.Printf("Hello World!")

the sample notebook is copied from gonb/examples/tutorial.ipynb at main · janpfeifer/gonb.

%% is special mark for it.

[mwouts]

Hi @HaveF , can you tell me a bit more about the %% marker in go notebooks? Also, I'd like to give you the authorship of the commit in the PR, would you like to open a PR yourself?

[HaveF]

Hi, @mwouts , Thanks for helping me out. I believe your PR is fine. I can help to test.

%% is not part of Go, but it is a shortcuts of GoNB. Anything after a "%%" will be wrapped inside a func main() { ... }

like

%%
fmt.Printf("Hello World!")

It will converted to this behind the scenes

func main() {
    fmt.Printf("Hello World!")
}

It can appears at any part of a cell, not just beginning of a cell, like:

var startValue = float32(1)

%%
startValue = incr(startValue)
fmt.Printf("current startValue=%f\n", startValue)

Do you see the error I mentioned before? Or, you can help to change in #1250, then I test it

[HaveF]

Other special notation in GoNB:

%% --who=world can pass flags to main func

import (
    "flag"
    "fmt"
)

var flagWho = flag.String("who", "", "Your name!")

%% --who=world
fmt.Printf("Hello %s!\n", *flagWho)

%args also can pass flags

%args --who=Wally

func main() {
    flag.Parse()
    fmt.Printf("Where is %s?", *flagWho)
}

!* notation run the command in special building dir

!*pwd ; ls -l

%test for test the current cell

import "github.com/stretchr/testify/require"

func TestIncr(t *testing.T) {
    require.Equal(t, 2, incr(1))    
}

func BenchmarkIncr(b *testing.B) {
    for i := 0; i < b.N; i++ {
        _ = incr(i)
    }
}

%test

other GoNB command

%track

%goworkfix

[mwouts]

Thank you @HaveF - that's very helpful! Well, I'm afraid this is going to be a little tricky...

Can I ask you one more question? How do you think that this notebook cell should be represented in the go:percent format?

%%
fmt.Printf("Hello World!")

Do you think that this might work for you? (is this a valid go file?)

// %%
%%
fmt.Printf("Hello World!")

[HaveF]

@mwouts Thanks for your help.
Yes, It is a bit tricky, because GoNB introduces shortcuts that are not originally part of Go.

// %%
%%
fmt.Printf("Hello World!")

Although this is not a valid go file, I think if someone uses GoNB, he should understand the meaning of %%.

• Or for greater clarity, we just call the jupytext file as *.gonb? Then just let the user configure gonb's syntax highlighting?
• Or just name the files as *.go, let users be responsible for understanding some special syntax of GoNB. This allows users to configure less content(I prefer this)

---

Hi, @janpfeifer (author of GoNB), jupytext's author(Marc Wouts) is help us to support GoNB in jupytext. We are now facing a problem with the correspondence between jupyter notebook and jupytext. Can you help us see if the above syntax correspondence is the most ideal? Or you have other ideas? Thanks!

[janpfeifer]

hi @HaveF , @mwouts

Thanks for following up on this, Jupytext looks awesome.

I was reading through Jupytext readthedocs page and I'm not sure I got all the details right -- for the py:percent format, the # %% marks the start of a code cell. What marks the end of the cell ? Is it until the next # %% tag ?

A few meta comments, from what I understood (I may be wrong):

1. The input for Jupytext could never be really proper Go, because either it contains statements in the global scope (which is not valid in Go) or it would have various definitions of func main(). So we can expect better IDEs to get confused.
2. Because of (1), I agree calling the suffix .gonb, since anything we come up with will be kernel dependent. And it serves to remind the user that there is some small special syntax to consider -- with the added pain of configuring IDE's syntax highlighting (one can always create a symlink from the .gonb file to a .go file)
3. About gonb special commands: what about prefixing them with //gonb: in Jupytext files ? (edited) Where Jupytext would remove any line prefixed with //gonb: and pass the rest of the line as is to GoNB I could change gonb to also accept special commands prefixed with //gonb:. This is somewhat aligned to special //go: special comments, but it clearly points out it is gonb related. It's lots of typing ... but usually they don't make most of the code.. Btw, %help lists all of the special commands in gonb with a description.
4. When using Jupytext + Go, one can always use various func main() {...} (one per cell) and never need to use any gonb special command. More typing ... but should be fine ?

Any thoughts?

Example of what a Jupytext+Gonb code would look like:

// %% [markdown]
// # Defining a $x^2$ function
// It returns x*x.

// %%
func Square(x float64) float64 {
  return x * x
}

// %% [markdown]
// # Examples
//
// ## Example A: $x = 3$

// %%
var x = flag.Float64("x", 0.0, "Value of x")
//gonb:%% -x=3
fmt.Printf("Square(%g)=%g\n", *x, Square(*x))

// %% [markdown]
// ## Example B: $x = 4$

// %%
//gonb::%% -x=4
fmt.Printf("Square(%g)=%g\n", *x, Square(*x))

This seems unambiguous, trivial to parse ... but not very pretty on the eyes 😄 (too many %%).

I would suggest an alias for the //gonb:%% special command, something like //main or something else ? Any suggestions ? Another option is to start with this verbose but full support format, and create the aliases later, after some use we may have a better ?

Btw, if (1) becomes a serious usability issue (IDE complaining of various func main), I could create a %main myFunc special command in gonb that would interpret myFunc to be main. So a cell would look like this in Jupytext:

// %% [markdown]
// ## Example C: $x=5$:

// %%
func exampleC() {
  fmt.Printf("Square(%g)=%g\n", *x, Square(*x))
}
//gonb:%main exampleC -x=5

[janpfeifer]

I just went for a hike and was thinking more about it: one of the benefits of the Jupytext file were named .go and were proper Go, is that it can be compiled and tested with normal Go (without Jupyter). It could even be code shared between a proper Go program (or test), and read as Jupyter Notebook (or kept paired with a .ipynb).

So I like even more the idea of having a //gonb:<special gonb commands>, but having the //gonb: prefix removed (in this case by Jupytext, if possible) when converted/synced to a notebook. And adding the special %main <func_name> args... special command to gonb.

The above example could look like a file squared.go:

package square

// %% [markdown]
// # Defining a $x^2$ function
// It returns x*x.

// %%
func Square(x float64) float64 {
  return x * x
}

// %% [markdown]
// # Examples
//
// ## Example A: $x = 3$

// %%
var x = flag.Float64("x", 0.0, "Value of x")

func example() {
  fmt.Printf("Square(%g)=%g\n", *x, Square(*x))
}
//gonb:%main example -x=3

// %% [markdown]
// ## Example B: $x = 4$

// %%
//gonb:%main example -x=4

This way this compiles in Go, and we can even create on the side a file square_test.go that tests that the results of example() are what one wants, or create a separate main.go and offer the same functionality from the command line.

Any thoughts ?

[HaveF]

@janpfeifer ❤️ Thanks for your constructive comments.

• If you can support some tweaks, //gonb: seems to be the simplest, and has a certain scalability solution. I don't know if it is easy to change in jupytext. Let's wait @mwouts 's thoughts 💭
• I don't know if it is necessary to make the files converted by jupytext more like real go. After all, this part of the work is already done by gonb (such as adding necessary imports, etc.). My original use scenario is actually, when jupyter lab is not so convenient to edit, I can switch to a modern editor to edit, even use AI to modify directly in the modern editor, and then reload the changes in jupyter lab.

[mwouts]

Hi @HaveF , @janpfeifer , thank you for your useful inputs! That's very interesting. And thank you for your kind comments too!

To follow-up on the above,

1. I do have a preference too for generating .go files rather than .gonb (users can still use a custom prefix, e.g. export nb.go:percent if they want to get e.g. a .nb.go extension)
2. I like the idea of mapping %% (followed by nothing, or by a space - e.g. that would exclude the usual magic commands) in notebooks to //gonb:%% in .go files, and back. That's simple enough.

I'll ping you when I get a development version that you can try to see how it works on real notebooks.

[mwouts]

I might have something that works with the percent and markdown formats (not yet with the "light" format):

HATCH_BUILD_HOOKS_ENABLE=true pip install git+https://github.com/mwouts/jupytext.git@support_gonb

(remove HATCH_BUILD_HOOKS_ENABLE=true if you don't have nodejs and if you don't need the Jupytext Menu).

Let me know how it works for you. Thanks!

[HaveF]

Wow! @mwouts Your speed is really fast! I tried it and it seems to be OK.

The corresponding go files can't really be go files(just forget about the IDE complaining 😄 ). I think it's pretty good (and simple) for now. I love it!

What do you think? @janpfeifer If you haven't used jupytext before, I suggest you try it, it's really useful!

[janpfeifer]

Very neat 😃 ! It's working here, see image below.

A couple of things:

• Jupytext (I installed the version you pointed out @mwouts , without the HATCH_BUILD_HOOKS_ENABLE=true) didn't filter out the //gonb: prefixes. Did I do something wrong ? Or was it not the intended goal ?
• I also had to add the --set-kernel gonb, otherwise Jupyter would always ask me the kernel when opening. Would it make sense to default the kernel for .go to gonb, or is it intended to be left up to the user ? (Maybe it's the same with python?)

I also updated gonb (in a branch only so far, if we are happy I'll create a release later today or tomorrow:

• gonb now ignores the prefix //gonb:: even though it would be nice if Jupytext would filter it out, I think it's a nice thing to have, if someone ever needs the code to be proper Go.
• It also now ignores any package declarations -- instead of being an error that won't allow the cell to run.
• I added a %exec <function> as an alternative to %%. Also, just in case.

I'm definitely using Jupytext to write my demos for GoMLX, another large project I maintain and relies on Jupyter Notebooks for examples. Jupytext will make it much easier to maintain.

For my testing:

File square.nb.go:

// %% [markdown]
// # Square Function
//
// Defines a function $f(x) = x^2$

// %%
func Square(x float64) float64 {
        return x*x
}

// %% [markdown]
// # Examples
//
// ## Example A: $x = 3$

// %%
var x = flag.Float64("x", 0.0, "value of x to feed f(x)")

//gonb:%% -x=3
fmt.Printf("Square(%g)=%g\n", *x, Square(*x))

// %% [markdown]
// ## Example A: $x = 4$

// %%
//gonb:%% -x=4
fmt.Printf("Square(%g)=%g\n", *x, Square(*x))

Yields the following notebook:

[HaveF]

hi @janpfeifer

1. You missed a space before gonb, //gonb:%% -x=3 should be // gonb:%% -x=3
   it should be

// %% [markdown]
// # Square Function
//
// Defines a function $f(x) = x^2$

// %%
func Square(x float64) float64 {
    return x*x
}

// %% [markdown]
// # Examples
//
// ## Example A: $x = 3$

// %%
var x = flag.Float64("x", 0.0, "value of x to feed f(x)")

// gonb:%% -x=3
fmt.Printf("Square(%g)=%g\n", *x, Square(*x))

// %% [markdown]
// ## Example A: $x = 4$

// %%
// gonb:%% -x=4
fmt.Printf("Square(%g)=%g\n", *x, Square(*x))

2. I don't know your I also had to add the --set-kernel gonb problem. It works great on my machine. I guess it is just because you write go file first. You should try create or open ipynb first, then pair, it will create a go file with front matter like this(I guess it is the reason why it is not ask me the kernel) :

// -*- coding: utf-8 -*-
// ---
// jupyter:
//   jupytext:
//     formats: ipynb,go:percent,md
//     text_representation:
//       extension: .go
//       format_name: percent
//       format_version: '1.3'
//       jupytext_version: 1.16.3-dev
//   kernelspec:
//     display_name: Go (gonb)
//     language: go
//     name: gonb
// ---

[janpfeifer]

Oh, thanks @HaveF ! I hadn't realize you start from the .ipynb file and then pair it. Indeed I started with the .go file.

Now about the space in between // gonb: -- this is less optimal because Go already have similar special tags (//go:generate, //go:build) without the space. The idea would be to keep it inline with the standard idiom without the space. What do you think ?

If you both agree, @mwouts would that work for you, have //gonb: without the space as a prefix ? It's also not super critical ... just a little cleaner 😃

In the GoNB kernel I can support both.

[mwouts]

Hi both, thank you for your feedback! Quick comments

Now about the space in between // gonb: -- this is less optimal because Go already have similar special tags (//go:generate, //go:build) without the space. The idea would be to keep it inline with the standard idiom without the space. What do you think ?

If you both agree, @mwouts would that work for you, have //gonb: without the space as a prefix ? It's also not super critical ... just a little cleaner 😃

Sure I can do //gonb:%%. Actually I intended to support both (e.g. remove //\s*gonb: when converting to a notebook) but I probably got my regular expressions wrong. I went for the version with a space for consistency with the cell marker (// %%) which has a space, but I can definitively generate //gonb:%% with no space (the space in the cell marker would be tricky to change, as we have it in all the languages, because e.g. Python formatters like black enforce a space after the comment char).

also had to add the --set-kernel gonb, otherwise Jupyter would always ask me the kernel when opening. Would it make sense to default the kernel for .go to gonb, or is it intended to be left up to the user ? (Maybe it's the same with python?)

I would have expected the contents manager to set a kernel in a matching language if you open a .go file that does not have a kernel yet. That's supposedly done by the set_kernelspec_from_language function. I will have a look later on. And you can use Jupytext in both ways, e.g. create your notebook either as a text file or in Jupyter.

I'm definitely using Jupytext to write my demos for GoMLX, another large project I maintain and relies on Jupyter Notebooks for examples. Jupytext will make it much easier to maintain

Thanks! As pointed out in the documentation, for writing documentation you might want to use one of the Markdown-oriented formats (the most advanced one is the MyST Markdown format, which works well with Jupyter Book), but of course the choice is entirely up to you. An example is included in the PR, see https://github.com/mwouts/jupytext/blob/support_gonb/tests/data/notebooks/outputs/ipynb_to_myst/hello_world_gonb.md

[janpfeifer]

+100 from my side: we get the best of both worlds, space for the cell makers (// %) and no space (//gonb:) for Go's Gonb (or use the regular expression and take arbitrary # of spaces).

Thanks for the pointers on the md format, I'll check that out for GoMLX!

[mwouts]

Great! I've updated the PR by the way, if you want to test the latest development version (I will follow-up on the default kernel later on, possibly in another issue).

[janpfeifer]

I just re-installed and tried it -- but I'm not sure if I'm getting the latest version -- but in one case the //gonb:... didn't get stripped.

The .go file with the contents:

...
// +
//gonb:!*rm -f go.work && go work init && go work use . ${HOME}/Projects/gopjrt
//gonb:%goworkfix
// -
...

When converted back to the notebook with jupytext mandelbrot.go --update --to=ipynb didn't remove the //gonb: prefix.

But maybe I didn't get the latest version ?

ps.: I'm doing a Mandelbrot fractal drawing example, I'll publish it as soon as I'm done.

[janpfeifer]

So I just wrote the following (typical for me) notebook: mandelbrot.ipynb and the corresponding, generated by Jupytext (using the command line) mandelbrot.go.

I notice that the special commands that start with a single % from .ipynb get commented out in the .go conversion:

.ipynb snippet:

!*rm -f go.work && go work init && go work use . ${HOME}/Projects/gopjrt
%goworkfix
%env LD_LIBRARY_PATH=/usr/local/lib

Converted .go snippet:

!*rm -f go.work && go work init && go work use . ${HOME}/Projects/gopjrt
// %goworkfix
// %env LD_LIBRARY_PATH=/usr/local/lib

An issue is that when converting this back to .ipynb, one doesn't get the original snippet (the // % stays the same).

But maybe I got the wrong version ...

[mwouts]

Hi @janpfeifer, thanks for the example! Very nice notebook! A few comments

I see that you are using the light format. There are two Jupytext formats for scripts: one with implicit or // + for cell markers (light) and the other one with // %% cell markers, the percent format. Both formats are expected to work equally well, however I'd recommend the second one as it is more explicit/has more support in IDEs (well for Python) (click on "pair with percent go script", or set "formats = ipynb,auto:percent" in your jupytext.toml file)

Re the round trip support, that matters a lot to me, so thanks for sharing that example! I'll get that fixed soon. Before that, I think it's worth chatting a bit more about the usual magic commands.

The most standard magic commands in Jupyter are the % magic commands. They are made of one to three % signs, immediately followed by a lower case letter, at the top of a cell.

Some languages have other magic commands. In Python for instance, ! indicates a bash command, so it's recognized as a magic command. I'd be happy to do the same for Go notebooks.

Magic commands are commented out when a notebook is exported to either a percent or light script, and un-commented when the notebook is converted back to ipynb.

Now, if we go back to the %% command of GoNB, it differs from the standard magic commands in two ways: a) it is not necessary at the top of a cell and b) it can be followed by a space.

I know you mentioned replacing it with %%exec. That would solve a) and the need for the gonb marker (I need it to escape %%, because the simple escape // %% confuses Jupytext into thinking that we're seeing a new cell).

Would it be a constraint for you to require that the command is always at the top of a cell? That's not a big deal for me, but I think the support for magic commands at the top of a cell is better tested.

My plan is to categorize the ! commands as magic commands, and add a few tests based on your notebook above. Do you see something else that you'd like to see? Do you think we will then have a complete classification of magic vs non-magic commands in Go? (May it happen that a magic command has a line break? it does in Python...)

[janpfeifer]

Thanks for the explanation.

So in my installation is a Ubuntu 24.04, python 3.12.3, using venv where I installed jupyterlab 4.2.3 and jupytext 1.16.3-dev and then did jupyter labextension enable jupytext. Jupytext doesn't show up as an extension to JupyterLab. The "Pair" commands don't show up in the command pallete in Jupyter (control+shift+C)

So I was trying to use jupytext from the command line, and I'm assuming I'm missing a lot 😃

I did follow the installation instructions and did jupyter labextension enable jupyterlab-jupytext. I also tried to install jupytext from the extension manager within JupyterLab (the left tab where it lists the installed extension), and even though the "install" button does something and doesn't report any errors, the jupytext never shows up in the list of installed extensions.

The command jupyter serverextension enable ... fails with Jupyter command jupyter-serverextension not found.

I did browse through the JupyterLab logs it prints out during execution, and the only reference to Jupytext I see is a line like:

[I 2024-07-04 06:56:13.893 ServerApp] jupyterlab_jupytext | extension was successfully linked.

Any ideas why it doesn't show up as installed ?

[janpfeifer]

Ok, after searching around, I found a stackoverflow question that suggests one should use instead jupyter server extension ... (Omg ... they could have accepted both, or at least just pointed out to the alternative format 😆 )

So I did:

(jupyter) $ jupyter server extension enable jupytext
Enabling: jupytext
- Writing config: /home/janpf/.venv/jupyter/etc/jupyter
    - Validating jupytext...
      jupytext  OK
    - Extension successfully enabled.

And now during the execution of JupyterLab I get the following in the logs:

[I 2024-07-04 07:08:42.835 ServerApp] jupyterlab_jupytext | extension was successfully loaded.
[W 2024-07-04 07:08:42.835 ServerApp] jupytext | extension failed loading with message: ExtensionLoadingError('_load_jupyter_server_extension function was not found.')                        
    Traceback (most recent call last):                                                                                                                                                         
      File "/home/janpf/.venv/jupyter/lib/python3.12/site-packages/jupyter_server/extension/manager.py", line 360, in load_extension                                                           
        extension.load_all_points(self.serverapp)                                   
      File "/home/janpf/.venv/jupyter/lib/python3.12/site-packages/jupyter_server/extension/manager.py", line 232, in load_all_points                                                          
        return [self.load_point(point_name, serverapp) for point_name in self.extension_points]                                                                                                
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^       
      File "/home/janpf/.venv/jupyter/lib/python3.12/site-packages/jupyter_server/extension/manager.py", line 223, in load_point                                                               
        return point.load(serverapp)                                                           
               ^^^^^^^^^^^^^^^^^^^^^                                                                                                                                                           
      File "/home/janpf/.venv/jupyter/lib/python3.12/site-packages/jupyter_server/extension/manager.py", line 150, in load                                                                     
        loader = self._get_loader()                                                                                                                                                            
                 ^^^^^^^^^^^^^^^^^^                                                                                                                                                            
      File "/home/janpf/.venv/jupyter/lib/python3.12/site-packages/jupyter_server/extension/manager.py", line 119, in _get_loader                                                              
        loader = get_loader(loc)                                                                                                                                                               
                 ^^^^^^^^^^^^^^^                                                               
      File "/home/janpf/.venv/jupyter/lib/python3.12/site-packages/jupyter_server/extension/utils.py", line 40, in get_loader                                                                  
        raise ExtensionLoadingError(msg) from None                             
    jupyter_server.extension.utils.ExtensionLoadingError: _load_jupyter_server_extension function was not found.                        

I hadn't realized that there are 2 extensions: jupyterlab_jupytext and jupytext. Do one need both ?

[mwouts]

Hi Jan, no you don't miss that much - the lab extension is just the "Jupytext menu". You can use a config file as an alternative.

To get the extension, can you uninstall both Jupytext and the extension that you installed manually, and reinstall them using the full compilation command, e.g.

HATCH_BUILD_HOOKS_ENABLE=true pip install git+https://github.com/mwouts/jupytext.git@support_gonb

You will need nodejs for this.

Note that I didn't change anything since the second dev release, so there's a bit more work needed on the magic commands.

[janpfeifer]

hi @mwouts thank you so much!

I had forgotten that I installed it without the hooks. After installing nodejs and reinstalled jupytext with the hooks enabled all worked fine.

The pairing is very convenient to be done automatically when editing the notebook or the text file!

[janpfeifer]

Hey, here it seems all working well. Any concerns @HaveF , @mwouts ?

I was thinking of creating a new release of GoNB with support for //gonb: (just in case) and a "New: Jupytext support" line on the highlights (see "jupytext" branch).

Do you have plans for any releases @mwouts ? Or should I mention installing from the branch ('@support_gonb`) for those wanting to try it for now and leave it like that for a while longer ?

cheers

[HaveF]

@janpfeifer I believe it is great. //gonb:%% in go works in my machine.

@mwouts Thanks your great work!

[mwouts]

Hi @janpfeifer , yes sorry I'd need a little more time - I'd like to support the ! magic commands that you mentioned a few days ago. Are these always at the top of a notebook?

Also, what were the remaining cases of unremoved //gonb: prefixes? If you don't mind I'd rather take care of them too.

After that I'd be very happy to publish a new release. I should be able to do so at worse on next Tuesday evening.

[janpfeifer]

No worries, no hurry.

In GoNB I don't require them to be at the top of the notebook. But they are executed before the cell Go code is executed, irrespective of where they are in the cell. But the common use case is not to mix shell (! and !* magic commands) and Go code in the same cell.

[mwouts]

Hi @HaveF , @janpfeifer , I've added a few commits to the PR. It should have support for the ! and !* magics. Let me know how it works for you - feel free to review it quickly at #1250 too. Thanks!

[janpfeifer]

Thank you @mwouts, it is great!

I just tried it, and all the special commands I tried (!, !*, %<some_command> and %%) all worked perfectly. I browsed through the #1250 and noticed your regex even include %%%, very forward thinking 😄

This time i tried to install the extension (HATCH_BUILD_HOOKS_ENABLE=true pip install git+https://github.com/mwouts/jupytext.git@support_gonb) on my laptop (Ubuntu 22.02) and it failed though (some nodejs dependencies mismatch). But it worked fine on my desktop (Ubuntu 24.02). Not sure it matters though, but I thought I would let you know.

[mwouts]

Great!

What is the compilation error exactly? You might need to upgrade nodejs (see https://jupytext.readthedocs.io/en/latest/developing.html)

[mwouts]

Jupytext v1.16.3 is now available on pypi! Thanks for your feedback on this topic, and for the patience re the release (the publish CI failed a few times due to another change...)

[janpfeifer]

Thanks @mwouts ! Very appreciated. I'm already advertising it in gonb's home 😄