Feature suggestion: `import_with_path`

[adamjones2]

Often I find it would be useful not necessarily to have full-blown dynamic imports, but just to be able to dynamically know what file it was that I imported. Ie. to be able to write something like:

local imported = import_with_path 'path/to/my/jsonnet/file.jsonnet'; // returns { path: 'path/to/my/jsonnet/file.jsonnet', jsonnet: <contents of file> }
local path = imported.path; // is 'path/to/my/jsonnet/file.jsonnet'
local jsonnet = imported.jsonnet; // is the result of "import 'path/to/my/jsonnet/file.jsonnet'"

A good use case is with ArgoCD declarations where you may want to import a file collecting all the Deployment, Service etc CRDs for an app but you also need to ensure those files are covered by the manifest-generate-paths annotation so the GitOps system knows to monitor those paths for changes. At the moment we're forced to specify every import twice, like

local myAppsCrds = [
  // App 1
  {
    deployment: {
      value: import 'path/to/deployment.jsonnet',
      path: 'path/to/deployment.jsonnet'
    },
    ... // other CRDs for App 1
  },
  ... // other apps
];

// For each, add `path` to Application annotations to mark as monitored, and add `value` to overall output

Wondering if that's something you'd consider as an addition to the language or if you know of any way to do something like this today in Jsonnet that I've missed.

[davidovich]

Hi, not entirely plug and play as you'd wish, but using std.thisFile insisde the deployment.jsonnet would give you the file path that could be harvested after the fact. You'd need to change the return value of your deployment jsonnet and encode that std.thisFile:

// in 'path/to/deployment.jsonnet'
function() // optional - make it a top-level function
   {
        value: manifest your deployment here,
        path: std.thisFile
   }

Then at consumer side:

  // App 1
  {
    deployment:  (import 'path/to/deployment.jsonnet')()
    ... // other CRDs for App 1
  },