The single-loader allows only one instance of Xvc to be run in a single process. This is no problem for the shell, but it looks like it won’t be possible to use multiple Xvc instances in a single Python process.

It’s possible to overcome this with an elaborate multiprocessing setup in the wrapper, but I won’t bother with it for now.

Another issue is the restart script. The if in that script that restarts the server doesn’t work; it always restarts the notebook server.

I removed some println! statements from xvc.py. There doesn’t seem to be anything in the library related to outputs.

Let’s search for how to check if a jupyter-lab command with the port 7979 runs in the background.

It looks like the bug is in the condition; it’s not -s, it’s -z.

Oops, yeah.

Let’s do a bit of tidying and check if the script is fixed.

I have a clippy warning with a new function that says these usually don’t take self as a parameter. This is for the pipeline new command, and it receives a self as an XvcPipeline object. It seems best to turn off the clippy warning for this.

I allowed two clippy warnings, and the script seems to work fine.

Let’s go on to copying the content from the Xvc README to the notebook.

There is an issue with the run-after-commit script. When Xvc commits the changes, the command we give is run again.

The issue is that git initializes the directory in the test-data/ directory, while xvc works in the current directory. I think we can either git init in the current directory or xvc init in test-data.

We’re already deleting .git and .xvc directories in the start-readme script. I think it may be easier to update git init to just initialize in the current directory.

Yep, let’s do it that way.

I see there are still extra outputs from the commands. We need to deal with this first.

I removed them, but there are still pink outputs. These are from dbg! statements, it looks like, or we’re initializing the output thread incorrectly.

Fixed those as well. I wrote up the xvc file list command examples as well. Now we have issues with xvc storage new s3 not running, and not even showing any debug output. We’ll deal with it in the next devlog, though.

To make debugging easier, we can add file deletions in the ./start-readme script to the notebook itself.

Instead, I’ll run my watcher run-after-commit.sh to ensure that the files are deleted after commits.

That may also work; you can use both as well.

I noticed cli-opts pass --no-system-config etc. by default. Let’s deal with this first.

I fixed that.

I’m testing whether we are in the directory that we should be in with xvc.root("--absolute"), but it looks like it’s not possible to pass a string argument to the command.

Let me take a look at this.

It looks like there have been some changes in optional parameter handling in PyO3. You may need to deal with keyword arguments with decorators.

Now, let’s try xvc.file().track() once more with dir-0001/.

It seems to be working now. With an existing directory, it doesn’t show an error.

What does xvc.file().list() show?

It shows a single string with \n in it. It looks like we need to handle this in the output thread.

I added a replace("\\n", "\n") to output_str at the end, but it didn’t make a difference. I tested in the notebook with list_result.split("\n"), and these \n characters are indeed CRLF. So Jupyter shows CRLF in strings with \n, and this is not something we should try to fix, I think.

You can search how to show \n characters in a Jupyter notebook with CRLF.

The output string should be fed into repr, as in:

# Define a string with CRLF characters
text_crlf = "Hello\r\nWorld\r\nThis is a test string."

# Use repr to show the \r\n characters explicitly
print(repr(text_crlf))

I tested this, and GPT misleads. repr is when you want to show \n, not vice versa. When I print(list_result), it prints the results properly.

It looks like we don’t need to make this a priority now. We can tell the user in the notebook that the commands are intentionally returning strings, and they can process or print them however they want.