Arduino-cli on Win10, "file" protocol in json

I've inherited an Aruino-cli project, with an arduino-cli.yaml file and a package_xxxx_index.json file. I need to configure the enviroment: my instructions say

arduino-cli core install xxxx:yyyy

When I do that, it loads the package index json file, and fails on

"url": "file:///docker/xxxx-2.0.0.zip",

I just downloaded arduino-cli: the version is 0.26.0. The package json was presumably valid 6 months ago, but would have been run in a (linux) docker image.

I can (and have) uploaded the zip to a web server, and run the core install with a http url, but what is going on? Is "file:" supported on some platforms? Do I have a permissions problem? Is it documented?
I'm just a beginner: this is my first day.

Hi @mlooser

Please post the exact output from the failure.

I tried using the file scheme in the packages[*].platforms[*].url field of a package index and got an error of this form:

Error during install: Get "file:///e:/foo.zip": unsupported protocol scheme "file"

I tried it with the version of Arduino CLI from that approximate time frame (0.21.0) and got the same error.

It seems to be intentionally not supported by the net/http Go package used by Arduino CLI to download the file:

Though it is possible to add support for additional protocols/schemes:

https://pkg.go.dev/net/http#Transport.RegisterProtocol

The documentation for the Arduino package index file is here:

https://arduino.github.io/arduino-cli/latest/package_index_json-specification

Hello again @mlooser. I thought of one possible explanation why someone might be given the impression that a file:// URL in a package index is supported:

For the sake of efficiency, Arduino CLI caches all tool, boards platform, and library archives downloaded by arduino-cli core and arduino-cli lib commands under the path specified by the directories.downloads configuration key. It checks that location for a file of the given name, and if the checksum validation passes, that file is used instead of downloading. This circumvents the code that uses the net/http Go package. So even if the protocol/scheme is not supported, the installation can still proceed.

It is possible the author of the package index did not realize the file was being sourced from an incidental copy at <directories.downloads>/packages/xxxx-2.0.0.zip instead of the expected /docker/xxxx-2.0.0.zip. You would get different results from them if you didn't happen to have the file at that location.

I was under the impression that he was using a json file that had been built using the Arduino IDE, but apart from that, everything you say is entirely reasonable -- all he had to do was download it once, and then the file: url would have "worked".

Unfortunately, I don't think he understood what he was doing beyond "I had to try some stuff, and then it worked", and he didn't document "but it only works on a system where you have previously downloaded the file from a http url" (a cached checksum)

I've not been able to get his docker image to work for me (separate problem). For all I know he left it running continuously, or never actually worked in docker at all.

Thank you for the pointer to the json documentation.

Yes, that would seem to be a reasonable thing for the Arduino system to do. And it looks simple.

But as a new user, I have no idea why any of the Arduino system is set up the way it is: maybe permitting local stuff is a bad idea for some reason.

I think this might be the answer. Arduino IDE 1.x has different code for handling the package index.

I see what appears to be an indication that Arduino IDE 1.x does support this:

That issue was closed as resolved by the addition of support for file:// scheme URLs in the board_manager.additional_urls configuration key, or --additional-urls command line flag, but the request in that issue for the ability to use such URLs within the package index was not fulfilled.

I am not knowledgeable enough about security matters to be able to say whether it would be a concern for Arduino CLI's usage. The discussion about the net/http package indicated that they thought such a capability could be dangerous in some applications though.