As far as I can tell, the Terraform SDK does not support an interface type. In my case I'm using a data resource to reach out to an API and pull JSON data. I would like to put that data in an attribute for later use in a resource but the problem is the JSON response has a large dictionary filled with different types. In GoLang this is no problem because you can set the map type to Interface{}. It would seem however that terraform only allows you to set the following types in a schema:
TypeInt
TypeString
TypeBool
TypeFloat
TypeInvalid
TypeList
TypeMap
Without support for interface how would you go about doing this correctly? The very ugly hack I have right now is converting everything to a string and then fixing the type once it is passed to the resource.
I asked on Hashicorp's forums and received a phenomenal answer here.
The synopsis is that casting to a string is currently the best solution. However there is a team working on making a new SDK design which would support newer capabilities to include arguments with dynamically chosen types.
Related
If you wish to see base line questions skip problem details and see summary
Problem Details
I'm not too familiar with gui programming but I'm trying to get the smach_viewer to work for a project I'm working on for my class in ROS noetic. I've resorted to pulling all of the source code and putting it my workspace which already makes it more manageable but while adapting the code in one of the python packages I ran into an error I can't make heads or tails of:
File "/home/hawk/final_project_ws/src/final-project-group-4-inc/src/xdot/xdot_qt.py", line 1914, in main
app.setWindowIcon(QIcon(":/icon.png"))
TypeError: 'PySide6.QtGui.QGuiApplication.setWindowIcon' called with wrong argument types:
PySide6.QtGui.QGuiApplication.setWindowIcon(QIcon)
Supported signatures:
PySide6.QtGui.QGuiApplication.setWindowIcon(Union[PySide6.QtGui.QIcon, PySide6.QtGui.QPixmap])
Above its saying that the function setWindowIcon has a supported signature, which is something I've never seen before. And within the supported signature it says that the parameter for the function looks along the lines of this: Union[QIcon, QPixmap](<-- summarized form). I've never seen Union[] thing before so that is new to me as well.
Summary
What is this error telling me?
What is a Supported Signature?
What is a Union[] supposed to be within parameters as shown in the suggested signature of the error?
So I found out supported signatures specifies what objects you can pass into a parameter.
Union is another way of saying the parameters should be this object or the other.
So the supported signature: PySide6.QtGui.QGuiApplication.setWindowIcon(Union[PySide6.QtGui.QIcon, PySide6.QtGui.QPixmap]) Is saying that function PySide6.QtGui.QGuiApplication.setWindowIcon() accepts an object of type Pyside6.QtGui.QIcon or PySide6.QtGui.QPixmap.
As Karate supports type conversion, I was wondering if it is possible to write a custom type conversion in such a way that I could write something similar to this in my .feature file
customType customTypeResponse = response
which should have the same semantic as
yaml yamlResponse = response
but for customType instead of yaml.
I think I found the code enabling the custom type conversion. But I am not sure about the extensibility.
Thus the shortest way might be to use the Java interop enabling something like this
def customTypeResponse = CustomType.convert(response)
Please let me know of any possibiliy of type conversion.
Yes, I strongly suggest just using Java interop and not complicating it further for now. Maybe in the future we'll have a better way to do contribute custom syntax (hint: look for the Plugin interface and how karate-robot uses it).
In NiFi, I have a flow file with an attribute RSID. I need to generate a UUID v5 based on RSID and add it as an attribute to the flow file. This uuid needs to be based on RSID because some reports will have the same RSID and need to thus have the same UUID5.
I've seen some methods in Groovy that will generate a random uuid, but not v5 nor based on a string. Is this possible to do in Groovy/NiFi? If so, how would this be done? I'm very new to Groovy.
You can indeed do this with Groovy and NiFi using the ExecuteScript processor. This SO post includes the code for generating a UUID v5 which you can apply to your RSID namespace. If you want some pointers on using the NiFi API from ExecuteScript, feel free to check out my cookbook series, hopefully it will help you assemble a working solution.
I have also written a Jira to add a UUID5 function to NiFi Expression Language, to make this easier.
We're currently working on a table powered by React Virtualized and using TypeScript.
At the moment we're looking at making a custom row render.
We started off by looking at the implementation of the defaultRowRenderer.
We took that code and started modifying it to our needs, and we noticed that there are two props it expects that aren't defined in the #types/react-virtualised type definitions.
key, and onRowRightClick.
So we dug a bit deeper and had a look at the types.js which is in the same directory as defaultRowRenderer.js and found that babelPluginFlowReactPropTypes_proptype_RowRendererParams also doesn't define those props.
We then had a look at the Grid and List folders, and their types.js files do contain the key prop in babelPluginFlowReactPropTypes_proptype_RowRendererParams (List) and babelPluginFlowReactPropTypes_proptype_CellRendererParams (Grid).
Should key, and onRowRightClick be defined in Table/types.js.
And if so is the fact they are missing the reason that they're also missing in the TypeScript definitions?
Or am I miss-reading the entire lot? ;)
And if so is the fact they are missing the reason that they're also missing in the TypeScript definitions?
The TypeScript definitions aren't maintained by me so they may lag behind the actual project for no good reason.
As for why those props are missing from the Flow type in the git repo- probably just an oversight. The type isn't a strict object type so additional properties aren't treated as an error. We should add them into the type and fix it though.
In Puppet 3 and prior, templates in defines inherited scope from their calling class the same way native defined types do, so if I had a file resource with a template source created by a define, that template could make use of variables set in the calling class no matter which class called the define.
In Puppet 4 (also tested with Puppet 3.8 future parser), that appears to no longer be the case, and it is causing breakage that is hard to even measure in my environment, which has relied on this behavior for tens of thousands of lines of code. Is there any way at all to get this back? After looking into it, even converting the defines into native types doesn't solve the problem, as they rely on the ability to gather server-side information about what templates are available in different modules via custom functions, and everything in a native resource type appears to happen on the client.
Is this fixable, or do I attempt to wait for Puppet 5?
Edit: Don't get too caught up in the word 'scope' here -- I need any way to pass all class variables to a define and unpack them there so that they are available to templates, or a way to have a native type see what files are inside specified modules on the puppetmaster. I will accept any bizarre, obscure message passing option as long as it has this result, because the classes do not know where the templates are -- only the define does, because it's making use of the helper functions that scan the filesystem on the server.
Edit 2: To prove this works as expected in Puppet 3.8.5, use the following:
modules/so1/manifests/autotemplate.pp:
# Minimal define example for debugging
define so1::autotemplate (
$ensure = 'present',
$module = $caller_module_name,
) {
$realtemplate = "${module}${title}"
file { $title :
ensure => $ensure,
owner => 'root', group => 'root', mode => '0600',
content => template($realtemplate),
}
}
in modules/so2/manifests/example.pp:
# Example class calling so1::autotemplate
class so2::example (
$value = 'is the expected value'
) {
so1::autotemplate { '/tmp/qwerasdf': }
}
in modules/so2/templates/tmp/qwerasdf:
Expected value: <%= #value %>
In Puppet 3.8.5 with future parser off, this results in /tmp/qwerasdf being generated on the system with the contents:
Expected value: is the expected value
In Puppet 3.8.5. with parser = future in environment.conf (and also Puppet 4.x, though I tested for this example specifically on a 3.8.5 future parser environment), this results in the file being create with the contents:
Expected value:
Edit 3: two-word touch-up for precision
In Puppet 3 and prior, defines inherited scope from their calling class the same way native defined types do, so if I had a file resource with a template source created by a define, that template could make use of variables set in the calling class no matter which class called the define.
What you're describing is Puppet's old dynamic scoping. The change in scoping rules was one of the major changes in Puppet 3.0; it is not new in Puppet 4. There was, however, a bug in Puppet 3 that templates still used dynamic scope. That was fixed in Puppet 3.5, but only prospectively -- that is, when the future parser is enabled. Defined types themselves went through the scoping change in Puppet 3.0.0, along with everything else. The scope changes were a big deal (and Puppet devoted considerable effort to alerting users to them) when they first went into place, but nowadays there's no big deal here.
it is causing breakage that is hard to even measure in my environment, which has relied on this behavior for tens of thousands of lines of code.
I'm sorry you're having that experience.
Is there any way at all to get this back?
No. Puppet scoping rules do not work the way you want them to do. That they did work that way in templates (but not most other places) in Puppet 3 was and still is contrary to Puppet's documentation, and never intentional.
Is this fixable, or do I attempt to wait for Puppet 5?
There is no way to get dynamic variable scoping in templates or elsewhere in Puppet 4, and I have no reason to think that there will be one in Puppet 5.
If you need a template to expand host variables from the scope of a particular class, then you can get that by evaluating the template in the scope of that class. Alternatively, an ERB template can obtain variables from (specific) other scopes by means of the scope object. On the other hand, if you want to expand the template in the scope of a defined type, then you could consider passing the needed variables as parameters of that type.
There may be other ways to address your problem, but I'd need more details to make any other suggestions. (And that would constitute a separate question if you choose to ask it here on SO.)