Need a way to reference file paths relative to the config file about dsc HOT 5 CLOSED

If git.exe is available, we can retrieve this information using git rev-parse --show-toplevel. I like the idea of letting Git own that task. Maybe there is a way to integrate?

from dsc.

@nkalayci is working on a project where the "nxScript" resource has been used. I think she could help us understand how customers reference commands that are not in path.

from dsc.

A normative pattern for this problem in other higher-order tools is to use something like a File resource to put content in a deterministic location on the managed nodes. Models differ on implementation:

• With Puppet's file resource, a user can specify the contents of the file in their config or reference a URI to retrieve the content from. Puppet uses the puppet:// URI to reference content shipped in a Puppet module (the normative way to ship config groups).
• Chef has the file resource for defining content directly or from managed-machine-local files, the cookbook_file resource to copy files from a chef cookbook (similar to using Puppet's file resource with a puppet:// URI), the template resource for templated content, and the remote_file resource for copying remote files.
• Ansible has the builtin.template and windows.win_template modules for creating files from templated content, the builtin.copy/windows.win_copy modules for copying files from local/remote machines, and the builtin.get_url/windows.win_get_url modules for copying files from URIs.

In the Ansible model, when using copy or win_copy, you can specify a local absolute or relative path for the source. When the path is relative, it's relative to the Ansible playbook (which for us is analogous to being relative to the DSC Configuration document).

I'm not against the idea of adding a built-in variable like $DSCConfigRoot, but I wonder if the semantics of "relative paths handled by DSC itself¹ are always relative to the configuration document" is better or worse. Alternatively, relative paths could always be relative to the current working directory, which is in line with how CLI tools generally behave. In that case, the $DSCConfigRoot (or similar) variable would unambiguously identify a location, but only when DSC is getting the configuration from a file, not from stdin.

from dsc.

I think that the danger of simply using relative paths is that all resources need to be aware of this, as does the caller. Allowing for something like [builtin('DSCConfigRoot')]/file.txt would make the path absolute, preventing resources from accidentally using a CWD relative path and/or DSC from needing to have path as a property type.

If a config has a parameter which is itself a path, what is the expectation here (please forgive my lack of knowledge on the exact CLI syntax for dsc):

C:\User\Foo> dsc config D:\config.yaml --parameter bar=.\parameterIsPath

Even this usage is suspect, but at least has a chance that the CWD will flow properly to wherever the parameter is consumed and result in C:\User\Foo\parameterIsPath (which would be my expectation as a user) rather than D:\parameterIsPath (which would surprise me given the invocation circumstance).

from dsc.

WG discussed this and proposes a new env var created by dsc.exe called DSCConfigRoot which contains the directory of the currently executing config file. The PowerShell group resource (and any other language group resource) would need to know to expand this before passing to resources:

$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
resources:
- name: Use class PowerShell resources
  type: DSC/PowerShellGroup
  properties:
    resources:
    - name: foo
      type: PsDesiredStateConfiguration/MSFT_File
      properties:
        Path: $env:DSCConfigRoot/bar/baz

In the future, for non-group used resources, we can have a function to resolve environment variables getEnvironmentVariable().

from dsc.