You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a PowerShell developer writing resources for use in v3 and compatible with PSDSC v1/v2, I want to ensure my resources participate as fully in the semantics of v3 as possible while continuing to write idiomatic PowerShell for my resources that works for PSDSC users.
As a configuration document author, I want to be able to define instances of resources that use well-known properties without having to be aware of how a given adapter handles those properties or remember differing conventions.
In PSDSC v1 and v2, resources used the Ensure (Present or Absent) convention generally, but not exclusively, for determining whether a resource should exist. In DSCv3, resources can define the _exist (true or false) well-known property for the same purpose, with the added benefit of DSC and higher order tools being able to add functionality for those resources (like know whether to call the delete operation or report messaging indicated a resource was created/updated/deleted).
In PowerShell, class properties are conventionally PascalCased. Having an _exist property beside Name, Version, etc is non-idiomatic and potentially confusing for users, who might naively think an underscore-prefixed property isn't meant to be used.
If the resource is implemented with the property as _exist, then everything works as-expected in the configuration document today, but creates a mismatch between PSDSC users experience and DSCv3 users. If the resource is implemented as Exist, then DSC and higher order tools need to use special handling for PSDSC resources.
In this case, the adapter would surface any resource with a boolean instance property called Exist that defaults to $true as _exist, using v3 semantics in v3 and idiomatic PowerShell in older versions of PSDSC.
Resource authors define the class with the _Exist property and alias it to Exist
This would enable v3/higher order tools to rely on the well-known property convention and non-v3 users/tools to use the more idiomatic Exist property name.
Resource authors using the (not-yet-developed) Microsoft.Dsc PowerShell module could inherit from a class like [DscResourceExistable] or some other convention that ensures the resource instance can handle defining both _exist and Exist
In this issue I'm pointing at the specific problem raised for the _exist property, but it isn't unique to that property - it applies equally to _purge and the other well-known properties.
The text was updated successfully, but these errors were encountered:
Summary of the new feature / enhancement
In PSDSC v1 and v2, resources used the
Ensure
(Present
orAbsent
) convention generally, but not exclusively, for determining whether a resource should exist. In DSCv3, resources can define the_exist
(true
orfalse
) well-known property for the same purpose, with the added benefit of DSC and higher order tools being able to add functionality for those resources (like know whether to call thedelete
operation or report messaging indicated a resource was created/updated/deleted).In PowerShell, class properties are conventionally PascalCased. Having an
_exist
property besideName
,Version
, etc is non-idiomatic and potentially confusing for users, who might naively think an underscore-prefixed property isn't meant to be used.If the resource is implemented with the property as
_exist
, then everything works as-expected in the configuration document today, but creates a mismatch between PSDSC users experience and DSCv3 users. If the resource is implemented asExist
, then DSC and higher order tools need to use special handling for PSDSC resources.Proposed technical implementation details (optional)
A few options come to mind:
Adapter translates the resource property for v3
In this case, the adapter would surface any resource with a boolean instance property called
Exist
that defaults to$true
as_exist
, using v3 semantics in v3 and idiomatic PowerShell in older versions of PSDSC.Resource authors define the class with the
_Exist
property and alias it toExist
This would enable v3/higher order tools to rely on the well-known property convention and non-v3 users/tools to use the more idiomatic
Exist
property name.Resource authors using the (not-yet-developed) Microsoft.Dsc PowerShell module could inherit from a class like
[DscResourceExistable]
or some other convention that ensures the resource instance can handle defining both_exist
andExist
In this issue I'm pointing at the specific problem raised for the
_exist
property, but it isn't unique to that property - it applies equally to_purge
and the other well-known properties.The text was updated successfully, but these errors were encountered: