Can we get an update on this enhancement? Is it something that will ever be worked on? This is issue #9 from 2014....

I don't think so. There is some objection to the idea because although in principle it's no more non-hermetic than regular file I/O and indeed you can use UNIX sockets or whatever to connect to curl and achieve the same thing, nevertheless it makes the config depend on having an internet connection, and URLs don't feel as static as files on disk.

The people who have needed this have implemented it using import callbacks or native callbacks, which works quite well. If you use native callbacks you have to do the cacheing yourself.

Feel free to keep asking though, if enough people want it, it would tip the balance.

(digression)

The people who have needed this have implemented it using import callbacks or native callbacks, which works quite well. If you use native callbacks you have to do the cacheing yourself.

Is there any reason why native callbacks could be preferred over import callbacks for that? I thought that native callbacks are supposed to be for pure functions only.

BTW probably the most mature discussion of jsonnet package management at the moment is ksonnet stuff here:
https://docs.google.com/document/d/1CQ3cQMH0WgoOpnVl_qFWhqMybE0IJIpkbJOu1xH6HFE

No, I think they used native callbacks because they didn't realize they could use import callbacks (although I may be mis-remembering this anyway).

What if we force the import string to include a checksum e.g. "https+sum://foo.com/bar#sha256:123456789abcdef..."

It would still suffer from:

nevertheless it makes the config depend on having an internet connection

But it would be hermetic.

Furthermore, a "file+sum:/...." URL would allow you to be stricter for local on-disk imports too.

I have a feeling that Nix might do that.

Why not just vendor it into your repo though, using jsonnet-bundler to manage that if you want.

With explicit hermetic imports, you always get the same thing, regardless of possible diamond dependencies

i'd like this feature

my use case is to import some external non-jsonnet json data in a secure way

the json data is not available at packaging time but will be available in a containerized environment at runtime (the name of the resource is well known and versioned)

python and shell are not to be included in the container image - ideally as few tools as possible