@viktorvan I know you were interested in the subscription stuff - this would probably help. I'm even thinking of putting in more checks like if you have multiple subscriptions, forcing you to supply one.

The way I imagine working with subscriptionIds would be either providing it as a string on the command line, or reading it as a string from an environment variable.

Maybe it would be useful with a SubscriptionId type with a parse function.

type SubscriptionId = SubscriptionId of Guid
module SubscriptionId =
  let parse str = Guid.Parse(str) |> SubscriptionId

but with some error checks and friendlier error messages probably :)

If it is kept as a Guid I still would need to parse it from my input string to a Guid, so it might as well be a “real” type I guess?

The Subscription Guid is created by azure, right, so I don’t think you’d ever would write code like
let mySubscription = Guid.NewGuid() so I don’t really care that the underlying type is a Guid, it’s just an identifier.

The way I imagine working with subscriptionIds would be either providing it as a string on the command line, or reading it as a string from an environment variable.

Doing so would be done outside of Farmer itself I think - I really don't want to have some "magic" environment variable that Farmer reads (maybe this could be a wrapper designed to make Farmer work OOTB for e.g. CI/CD processes...).

The Subscription Guid is created by azure, right, so I don’t think you’d ever would write code like
let mySubscription = Guid.NewGuid() so I don’t really care that the underlying type is a Guid, it’s just an identifier.

Making it a GUID rather than a string at least lets us confirm if the string supplied is a valid GUID - maybe someone uses an environment variable and mistypes the environment variable key or similar.

Doing so would be done outside of Farmer itself I think - I really don't want to have some "magic" environment variable that Farmer reads (maybe this could be a wrapper designed to make Farmer work OOTB for e.g. CI/CD processes...).

Yes, I do not suggest using any magic, the point I was trying to make was what it would be like to use this feature:

In my farmer-project I would get the subscriptionId from my configuration (in one way or another), for example

let mySubscriptionId = 
    System.Environment.GetEnvironmentVariable "MY_SUBSCRIPTION_KEY" 
    |> Guid.Parse

let template = ...

template.Deploy ("my-resource-group", [], mySubscriptionId)

I would have to parse my string to Guid. And in that case I think it would make sense to have a SubscriptionId type so I instead can do:

let mySubscriptionId = 
    System.Environment.GetEnvironmentVariable "MY_SUBSCRIPTION_KEY" 
    |> SubscriptionId.parse

But maybe it's overkill.

Making it a GUID rather than a string at least lets us confirm if the string supplied is a valid GUID - maybe someone uses an environment variable and mistypes the environment variable key or similar.

Yes, I agree that it should at least not be a plain string :)

This PR will never get merged, but it is useful to have as an example of what a new API could look like.