FFI: Loading libraries as dependencies/URLs

[kriszyp]

Currently Deno.dlopen takes a file path to load a binary library for use with FFI. However, in developing third party packages that use FFI, it seems like we would want the binary library to be treated like another dependency, like modules, accessible as a URL as part of the distribution (either absolutely or relatively). If I understand correctly, Deno works hard to abstract away the concept of "files" when dealing with modules, preferring to access them through URLs (and caching them in its own directory). It seems somewhat antithetical that FFI should be based on direct access to files. In particular, this seems like it creates a problematic distribution process; in order to load the binary library as part third-party package, we would need to:

• Check if the binary library file exists
• If it does not exists, fetch it from the source URL
• Save it to the file system (and figure out a good place to save it)

All of this is basically reinventing the wheel of dependency fetching/caching that Deno usually provides, and requires unnecessarily elevated permissions to accomplish.

Perhaps I am missing something about how this is supposed to work? Or should there be a way to access and load FFI binary libraries in a similar referencing manner as other dependencies/modules?

I know this has been discussed a little bit previously, so there may already be ideas for how this should work, but if you are looking for suggestions, maybe something like this would be a reasonable way to load an FFI library:

// URL/path is pretty much always going to be dynamic
const urlForBinary = 'https://cdn.com/lib.' + (os == 'windows' ? 'dll' : 'so');
const binaryFile = await import(urlForBinary, { assert: { type: 'binary' } });
const lib = Deno.dlopen(binaryFile, { ... all my symbols ... });

(binaryFile could be a File or something completely opaque that Deno could use to pass the cached file path to the OS to load the library).

[lucacasonato]

Also see #3448

[kriszyp]

I guess this also very closely related to #12770 .