Variables in double parentheses in YAML file - yaml

I am working on a pipeline and bumped into YAML file with multiple variables inserted with double parentheses, e.g. ((project_name)). Google surprisingly was not helpful with that. What can it mean/do? Based on studying the repository some of them refer to the global variables in the config directory, some however are nowhere to be found. Thanks for help, I am new to YAML!

Related

How to use $ (dollar sign) ^(exponent sign) in yaml?

I saw a YAML file that includes some signs like $, ^. For $, I think it tries to get value from a JSON file. But for ^, I'm not sure about that.
I tried to search for the YAML syntax but cannot find the usage of those signs.
Could anyone point out where that usage from? Thanks a lot!
examples:
json: $.A.Documents[*]
input: ^.B.ID
YAML doesn't assign any special meaning to those characters. As far as YAML is concerned, they are simply part of the content.
Of course, the software loading that YAML can do anything with the loaded data – including inspecting the loaded scalars for $ and ^ and implementing some action on them.
While someone might be able to correctly guess which software expects a YAML file like the one you show, it would be vastly easier for you to check the context in which you found that YAML file. This should lead you to the information you seek – i.e., for which software that YAML file has been written. That software's documentation will then describe how those characters are processed.

exclamation marks around a string in yaml

In a yaml config file created by OpenMapTiles I found the following syntax:
table: (SELECT geometry, class FROM layer_water(!bbox!, z(!scale_denominator!)))
The strings enclosed in exclamation marks obviously will be substituted by some provided values. My question is, how would this be done? I did not find anything about such a syntax for variable substition in yaml. Can someone please point me in the right direction?
Or is this meant to be dealed with AFTER parsing yaml?
Regards Oliver
I found it.
The syntax is special to Mapnik and in my case to the PostGIS Plugin.
The PostGIS plugin supports several special tokens. You can use them in subqueries and Mapnik will replace them at render time.

how to space multiple lines in github issues

I am copying a bunch of log output to a github issue and I want to indent it so that it is distinguishable as code/output from the rest of the issue.
How do I do this?
I tried:
CTRL+Tab
CTRL+[
CTRL+]
CTRL+Spacebar
but none seem to work? I really don't want to do every single line individually..
Wrap your code inside ```.
You can also specify language name after if your log file is analogus to any programming language's syntax.
e.g.
```yaml
You can refer Gihub Flavored Markdown for more info.

Ruby organization with multiple source files

I am trying to figure out the best way to organize a bunch of Ruby scripts to make it easier on the next person. One key thing is that there are multiple constant variables that need to be used across all scripts. Where should these be stored? Do I keep a separate file for these constants? Should I use YAML? I've never had to create a project with multiple Ruby source files interacting with each other, so I'm not sure as to what the best method of approach is here.
Thanks for the help.
I like to use a config.yaml file for all my constants. This makes it easy to set and change variables that are going to be used across different files. Then all you need to do is read in the file and set the variables. You can keep this file anywhere really, so long as anyone using the file has read permissions. All you have to do then is set the file path.
Hope this helps.
I like to do a config.yml or settings.yml, but I also allow the variables defined in config.yml to be overloadable by ENV variables (might be overkill in your situation).
It's might also be a good idea to set some defaults in your config loading/setting code.
As far as common functions/methods go... common.rb is a pretty good name or maybe shared.rb.

Should environment variables that contain a executable-path with spaces also contain the necessary quotes?

When defining an environment variable (on Windows for me, maybe there is a more general guideline)
set MY_TOOL=C:\DevTools\bin\mytool.exe
if the tool is located on a path with spaces
set MY_TOOL=C:\Program Files (x86)\Foobar\bin\mytool.exe
should the environment variable already contain the necessary spaces?
That is, should it read:
set MY_TOOL="C:\Program Files (x86)\Foobar\bin\mytool.exe"
instead of the above version without spaces?
Note: In light of Joeys answer, I really should narrow this question to the examples I gave. That is, environment variables that contain one single (executable / batch) tool to be invoked by a user or by another batch script.
Maybe the spaces should be escaped differently?
I'd say, do it without quotes and use them everywhere you use the variable:
set MY_TOOL=C:\Program Files (x86)\Foobar\bin\mytool.exe
"%MY_TOOL%" -someoption someargument somefile
Especially if you let the user set the value somewhere I guess this is the safest option, since they usually tend not to surround it with quotes rather than do so.
If there are plenty of places where you use the variable you can of course redefine:
set MY_TOOL="%MY_TOOL%"
which makes things more resilient for you. Optionally you could detect whether there are quotes or not and add them if not present to be totally sure.
When your variable represents only a path to a directory and you want to append file names there, then the "no quotes" thing is even more important, otherwise you'd be building paths like
"C:\Program Files (x86)\Foobar\bin"\mytool.exe
or even:
""C:\Program Files (x86)\Foobar\bin"\my tool with spaces.exe"
which I doubt will parse correctly.
The command shell can answer your question: type C:\Pro and hit the tab key.
Autocomplete will leave all spaces as-is and add quotes around the filename. So, this is what is "officially" expected.
(this assumes that autocomplete is turned on, I'm not sure whether the default is on or off, but most people have it on anyway, I guess)

Resources