Since Python functions are now generally available, I was wondering when we can expect them to be supported in the Workflow Builder for tracking and updating in the respective applications.
Hi @Flackermann
Usages of Python function should already be visible in Workflow Builder. Specifically it should already be possible to see any Workshop applications, actions, etc that use a Python function. If you have a usage that is not showing, please let us know and we can try to reproduce the issue on our end.
Unfortunately, due to the untyped nature of Python as a language, we are unable to provide detailed information regarding what a Python function may be using. At best, we will be able to provide a link between a Python function and any OSDK packages that the repository uses as a whole, but we will not be able to provide granular information about which objects/properties are used in a specific Python function in the repository.
I do not have an estimated timeline for providing links between Python functions and the repository’s OSDK usages. If granular object/property usage per function is important to you, please let us know.
1 Like
I have a Python repository that was previously on the V1 osdk generator and now runs on the V2 generator. When I open the workflowbuilder from the repository, it says this:
So it does show its usage in workshop, but still raises the warning, which is a little bit confusing.
I do understand that it is difficult to inspect the functions to check which objects are called / object apis without executing them. In my case, I make heavy use of the foundry-platform-sdk since I am running a library inside and outside of Foundry where we dont want to rely on the re-generation of the ontology_sdk (new versions) and also since we appreciate the (Beta-)Async-Client.
The only thing that I can imagine would be that the FoundryClient tracks the metadata of what was actually called in the API to do the function lineage in workflow builder. But yeah, this means that it needs at least 1 successful execution and would not necessarily account for all logic flows in the function…
Ah sorry for the confusion on that warning. The word “dependencies” in that warning is explicitly about things the function is using like objects. Usages of the function still show up correctly, as you can see by the linked Workshop. I’ll see if we can improve the wording here to be more explicit.
Yes, one option here is to try and record whatever was accessed in the recent usages of the function at that version, but as you pointed out, this will be an incomplete picture. Another idea proposed was to allow users to declare in their code which objects are used via a decorator or something similar, but in my opinion, that kind of additional documentation will end up out of date at some point.
Thank you for the clarification. I think I was also thrown off because the warning symbol is on the upper right corner which led me to believe it had something to do with the outputs since they are also on the right side. A better wording should suffice though.
You are right about the code documentation! I can’t imagine how tedious it would be to maintain the relationships in monocle except by reading it directly from the in- and outputs of the transform decorator. The decorator itself ensures the registration of the metadata though…
The question is: Do we want to document all object types that are visited within a function, or only those that are used as inputs / outputs and those that are modified?
If I consider the book “A philosophy of Software Design”, one should not care too much about the internals of a function. Only about the signature and possible side effects. Hence, Edits are already caught and validated against what you specified in the function(edits=) decorator.
So imho: Looking at the pure signature of the function and its type annotations would be good enough to check what are the direct dependencies. Yes, you may miss functions calling link types if you made some breaking change. Updating the OSDK in the python repo will give you plenty of linting errors of such a case occurs…
In conclusion: Track everything that is typed (inputs and outputs of ObjectTypes, ObjectSets and sequences / lists of Object Types). Do not try to go after what someone does with a primary key of an object that is handed over as a string parameter…