Add more file functions to stdlib

[nikolay]

So far, the only function for file paths is std.thisFile, but its utility is questionable.

We need functions giving us the full pathname of the current file, just the filename, and just the directory. It would be even better if we can get a function that extracts the filename, and the directory of a given file path, too.

I've been trying to use importstr and include configuration files, but I cannot make it work when the containing file is symlinked and it uses relative to its configuration files. Of course, the same applies to import, too.

[sbarzowski]

I think we could add operations on paths. That sound pretty useful. It doesn't require anything special from the language, so it could be a separate library as well.

Functions like:

unixDirname(path)
unixBasename(path)
unixJoinPaths(path_array)
unixExtension(path)
.
.
.

I've been trying to use importstr and include configuration files, but I cannot make it work when the containing file is symlinked and it uses relative to its configuration files. Of course, the same applies to import, too.

I'm not sure I understand how it relates to the previous point. Could you describe what you want to do in more detail? Am example of how you think the new API may look like in the context of your problem would also be useful.

[nikolay]

@sbarzowski There are uses cases where I need to imported file to be relative to the symlink's target and in others - to the symlink's source. On top, the documentation does not state clearly if the import is relative to the importing file's source or target if it's a symlink. If not a symlink, I'm still unsure if the imported file path is relative, to what it is relative to then.

[sbarzowski]

@nikolay

the documentation does not state clearly if the import is relative to the importing file's source or target if it's a symlink. If not a symlink, I'm still unsure if the imported file path is relative, to what it is relative to then.

Good point, thanks for catching this. We should definitely have it in the docs.

It's relative to the current file or to any of the library paths (specified with -J commandline option or JPATH env variable). Not sure about the symlinks, though. I'm gonna try that later.

[sparkprime]

Agreed this should be documented better. At the moment it's defined by implementation - the filename is the one used to open the file, and the "current working directory", i.e. the string used to absolutize relative paths in imports in that file, is just the directory removed from the filename.

The stdlib is weak even regarding basic string tasks like finding a substring. Definitely there is work to do there.

[sparkprime]

Other than the functions sbarzowski listed, and documentation of the meaning of the current directory when importing a symlink, is there any other action item here?

[seh]

It would be nice to have function that could resolve the "real path" of a file, or canonicalize it.

Today I noticed that std.thisFile can fail to include the containing directory name, when it has several ".." path components littered throughout. My locally crafted dirname function mistakenly "works" by yielding a directory path ending in "/..," instead of the intended containing directory name.

This strange import path is the result of arriving at this file by way of the interaction of the jsonnet_library and jsonnet_to_json Bazel rules.

[bcatubig]

It would be nice to have a glob function that could find files based on the glob match and return them in a list.

[tristan957]

It would be cool if there was a function to determine of a file existed in order to support optional importstr.