@mjkkirschner I am still not sure how the access token is going to be used by authors. At the node implementation level ?
ExecutionSession is a static, but is it accessible from all the Node code paths an author might write code in ?
I would hope we can alter this later without having jumping through all the "breaking public APIs" hoops

@pinzart90 - yes, any node author can access an execute session, from ZT, python, or NodeModels.

Unfortunately @saintentropy showed me an example of the DX nodes where this implementation will not work - it's a UI node that requires auth before the graph is executed - so I will change this implementation to support that use case as well.

@pinzart90 - yes, any node author can access an execute session, from ZT, python, or NodeModels.

Unfortunately @saintentropy showed me an example of the DX nodes where this implementation will not work - it's a UI node that requires auth before the graph is executed - so I will change this implementation to support that use case as well.

So just to confirm, the token will be available to authors pre-graph execution, as opposed to what the PR description says (that you may implement that later)?

@pinzart90 - yes, any node author can access an execute session, from ZT, python, or NodeModels.
Unfortunately @saintentropy showed me an example of the DX nodes where this implementation will not work - it's a UI node that requires auth before the graph is executed - so I will change this implementation to support that use case as well.

So just to confirm, the token will be available to authors pre-graph execution, as opposed to what the PR description says (that you may implement that later)?

yes, that's correct @zeusongit - I will update the PR description when this is ready for another look.

@pinzart90 if you are concerned that this API may change or need some more iteration cycles we can leverage the experimental attrbiute:
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-12.0/experimental-attribute

this will require package authors to opt-in explicitly to using this experimental feature or they will get a compile error. I personally would like to see this approach taken more often to avoid the buildup of WIP APIs we cannot remove.

@pinzart90 if you are concerned that this API may change or need some more iteration cycles we can leverage the experimental attrbiute: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-12.0/experimental-attribute

this will require package authors to opt-in explicitly to using this experimental feature or they will get a compile error. I personally would like to see this approach taken more often to avoid the buildup of WIP APIs we cannot remove.

@pinzart90 @aparajit-pratap 😢 - so because the DynamoServices dll targets netstd2 and not net8 we cannot easily use the [experimental] attribute - Is there still a good reason that DynamoServices does not target net8? Something to do with LibG or package authors still targeting net48? Can we move everything up to net8 now?

e targets netstd2 and not net8 we cannot easily use the [experimental] attribute - Is there still a good reason that DynamoServices does not target net std 2? Something to do with

The only reason for netstd2 was to be compatible with net48 at the same time. If we no longer want to do releases of LibG for net48 or if we want to do multi targeting (which complicates the CICD process) then we can move it on up.

@mjkkirschner what version of DynamoServices (net8 or std) will be used by nuget restore when consumed in a net8 csproj?
Hopefully nuget knows to restore exact matches with the highest priority

@mjkkirschner what version of DynamoServices (net8 or std) will be used by nuget restore when consumed in a net8 csproj? Hopefully nuget knows to restore exact matches with the highest priority

I can verify, but it should be the highest matching framework target IIRC.

@mjkkirschner what version of DynamoServices (net8 or std) will be used by nuget restore when consumed in a net8 csproj? Hopefully nuget knows to restore exact matches with the highest priority

I can verify, but it should be the highest matching framework target IIRC.

confirmed @pinzart90 - it picks the right one based on the target of the referencing project.