Add functions from path/filepath

[tredoe]

Have been added all functions from "path" (https://godoc.org/cuelang.org/go/pkg/path) but I need them from "path/filepath" to be compatible with the target operating system.

For now, what I need is "filepath.Join" and "filepath.IsAbs".

[adieu]

The need for path/filepath is legit. The problem is whether we should have two packages for both path and path/filepath or just one.

Once it's decided, I can send a PR for this issue.

[tredoe]

Some functions in "path/filepath" are not in "path", i.e. filepath.Abs() (which I need).

[tredoe]

"Path package should only be used for paths separated by forward slashes, such as the paths in URLs".
"package filepath implements utility routines for manipulating filename paths".

They are both in the standard library to be used with different paths, and a configuration language like CUE should be able to handle filename paths.

[mpvl]

There is a reason these don't exist yet: path is hermetic. filepath, however, is OS-specific, and thus not hermetic. It is deterministic, however. So I think it fine to add it to pkg/tool.

So there are two major decisions to be made before this can be added:

• Are we okay with having builtins in pkg/tool that can only be used in the tooling layer (I think it is okay; it just needs to be implemented properly)
• What would be the location of the two packages. I suggest:
  • pkg/tool/filepath or pkg/tool/file/filepath

There are several benefits to using different package names. Open to other layouts.

This should not be too hard to do. The package could be generated using cuelang.org/go/internal/cmd/qgo. We just need to ensure that the pkg/tool/filepath packages won't be available within non-*_tool.cue CUE files.

[rudolph9]

* Are we okay with having builtins in `pkg/tool` that can only be used in the tooling layer (I think it is okay; it just needs to be implemented properly)

I think that would be OK. One somewhat comment; I have desire to import tools from other packages. I know that packages are not fully defined but something to consider especially if we're adding more builtin packages that strictly tool packages.

[tredoe]

* Are we okay with having builtins in `pkg/tool` that can only be used in the tooling layer (I think it is okay; it just needs to be implemented properly)

If there is not other option.

* What would be the location of the two packages. I suggest:
  
  * `pkg/tool/filepath` or `pkg/tool/file/filepath`

I would prefer pkg/tool/file/filepath to follow (everything possible) the paths of the standard packages.

[mpvl]

There has been an increasing desire to evaluate tool files as data as well. This complicates simply adding such builtins. As their output depends on the environment, they are not hermetic and tools like trim are useless or even dangerous.

One way around this would be for these builtins to return some stub (a new internal type or so) that would always return an "incomplete" status by default, but that would become "activated" when running in tool mode.

Other than that, I think pkg/tool/file/filepath is a fine location.

[myitcv]

filepath, however, is OS-specific, and thus not hermetic

I've found myself needing the OS-specific behaviour in pure CUE. That is to say, I know exactly what OS' behaviour I need in a given situation. Part of the "issue" with path/filepath is that GOOS is a hidden part of the API. What we could do therefore is make the API for path/filepath accessible in some way via explicit OS identifiers. e.g.

import "path/filepath"

// ...

x: filepath.Windows.IsAbs(y)

[mpvl]

These have been added in the path package. CUE now supports variable arguments and the appropriate functions now take an OS argument.

Right now, the OS can be passed manually using injection via @tag. The idea is that to add a feature to injection to make this more automatic down the road. For instance:

import "path"

_os: *null | string @tag(os,inject=os)

// Split the directory based on the current os.
path.Split(dir, _os)

[mpvl]

Leaving this open to also track the addition of the @tag feature.

[cueckoo]

This issue has been migrated to cue-lang/cue#222.

For more details about CUE's migration to a new home, please see cue-lang/cue#1078.