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.

🐢 Yep. It was a nice October. I would like to finish by increasing the coverage.

🐇 How about setting up a runner on your machine to test them locally?

🐢 Not now. I should fix the tests as always. Later I can take a look at it. I don’t want to distract myself with it.

🐇 You’ll need to create Apple Silicon binaries, though.

🐢 I think I can cross-compile for aarch.

🐇 You were doing this in the past, trying to build all binaries on a single Ubuntu VM. It didn’t work, as far as I remember.

🐢 I hadn’t even read this section then, and there is a dedicated project for it. The proper way is to use that. I’ll return to this after fixing the tests. I think we can release Xvc on all platforms supported by Rust.

🐇 Using cross-rs on GitHub Actions may be challenging. It seems Apple Silicon doesn’t need that much work either. You can set up cross-compilation with rustup targets.

🐢 Yeah. It looks so. Let’s take a look at the previous devlog.

🐇 The page seems missing. Would you like to fix your site first?

🐢 Ah, yeah. I should, maybe. Now it’s time to fix those PRs. I’ll take care of the site later. I should change the theme anyway.

🐇 Ok. Let’s take a look at outstanding PRs.

🐢 I want to fix the failed tests locally first. Yesterday I wasn’t able to redirect the output. It looks like the correct way of doing it is cargo test --all-features --no-fail-fast > $TMPDIR/xvc-test.log 2>&1. It’s required to put 2>&1 at the end, not between the redirection and output.

🐇 There is also the &> operator that you may want to use. cargo test --all-features --no-fail-fast &> $TMPDIR/xvc-test.log should be equivalent to this.

🐢 I’ll try it when the tests finish.

🐇 In the meantime, you can work to fix the documentation. In another repository, perhaps.

🐢 Good idea. Let me clone that.

🐇 Looks like the tests have finished and the only error is Minio. It couldn’t find the env variables you defined.

🐢 Restarted the shell and the tests. Returned to docs now.

🐢 Added a few function docs. Storage tests seem to pass. Probably they will fail in GA because of rsync tests using one.emresult.com login in my name.

🐇 If that’s expected, you can push and begin to fix it.

🐢 Yeah, let’s push the tests.

🐢 It looks like connecting to localhost also poses a challenge. Instead, I can create a user for xvc on the server and limit its usage.

🐇 Hmm. Good idea for now.

🐢 I created a new user xvc-test@one.emresult.com and its SSH keys. I’ll update the action to write the secret to the keyfile.

🐇 Looks like you forgot to install mc for Minio connection.

🐢 Yeah, I must convert Minio tests to use s3cmd.

🐇 And your region in s3 configuration seems to be wrong.

🐢 I’ll need to check this.

🐇 There is this line in the tests let region = env::var("AWS_DEFAULT_REGION").unwrap_or("us-east-1".to_string()); that’s probably causing that error. You should define the region properly.

🐢 I set this to eu-central-1 directly and will check the Minio error in the next session.

🐇 👏

🐢 It’s working except for the rsync tests now.

🐇 I think you can just use localhost to run the tests. You may need to install openssh-server, but it should work with localhost without configuration.

🐢 There may be a step missing in the configuration. I’ll try to make it run.

🐢 I’m trying to use .ssh/config in GA to allow connections to the server. It doesn’t work for some reason.

🐇 You may try to log in to the server outside of the tests and check if it’s running.

🐢 Yesterday’s last attempt was successful, and now we have working remote storage tests.

🐇 👏👏👏🥳

🐢 I’m merging the PR.