devlog 4
Let’s start by looking at the debug output issue. We can start by replacing the eprintln! macros by println maybe.
I replaced eprintln’s with println but it doesn’t make any difference. Maybe we can remove those statements completely.
I can’t really find the place which kills the kernel. The last command runs is `xvc file list
print(xvc_test_data.file().list("test-data/dir-0002"))
and the output it produces it is
[src/output.rs:144:13] &output_str = "SS 131 2024-06-05 08:57:11 41e16be7 test-data/dir-0002/file-0003.bin\nSS 131 2024-06-05 08:57:11 27f0
efd0 test-data/dir-0002/file-0002.bin\nSS 131 2024-06-05 08:57:11 66de5084 test-data/dir-0002/file-0001.bin\nTotal #: 3 Workspace Size:
393 Cached Size: 6006\n"
print may be causing the death but more likely cause is the command that comes after this:
!ls -l test-data/dir-0001/
I replaced this with lsd which also failed. Maybe it’s really a Python death or bug.
The way to understand is to create a notebook file with only that cell and try to run it.
ls line runs fine with a new notebook. It even runs on Readme file when run in the beginning. The line that makes kernel die is
xvc_test_data.storage().new_s3(name="backup", bucket_name="xvc-test", region="eu-central-1", storage_prefix="xvc-storage")
You can start by removing new_s3 part.
The storage() method runs fine. It returns an XvcStorage() object as it should do.
When I run storage().list(), it takes a very long time. Probably the bug is something related to storage()
It looks storage object is adding file instead of storage as a subcommand. Fixed it now.
The bug was that. Readme notebook now creates the S3 storage.
What was the reason behind this?
Parsing the CLI to XvcCLI object was the culprit perhaps. Let’s take a look at more clearly.
Let’s try xvc file new s3 as a command to see how it will behave?
It says unrecognized subcommand for new.
This is what it should be but why it doesn’t work for XvcCLI parser, I wonder.
Anyway, it’s already 13:00 and let’s stop this for today.