In Puppet and Hiera, you often need to work with structured data in
hashes and arrays.
In the Puppet language, you can access hash and array members with
square brackets, like $facts['networking']['fqdn']. Hiera doesn’t use
square brackets; instead, it uses a key.subkey notation, like
facts.networking.fqdn.
This is for 5.2. Is there the same functionality available in 3.8? I could not find it in the documentation.
Is there the same functionality available in 3.8?
No. Puppet 3 -- which is obsolete and no longer supported -- uses Hiera version 1, which does not support the key / subkey syntax. You need at least Puppet 4 / Hiera 3 for that, but even that's very old. The latest Puppet is v6.4 (with Hiera 5).
Related
Let us say that I have worked on a haskell library and am now ready to release a beta version of the software to hackage/make repo public on github etc.
Possible Solutions and why they do not work for me
Use packagename-0.0.0.1-alpha or similar.
The problem here is quite simple: The Haskell PVP Specification does not allow it: (bold is me)
The components of the version number MUST be numbers! Historically Cabal supported version numbers with string tags at the end, e.g. 1.0-beta This proved not to work well because the ordering for tags was not well defined. Version tags are no longer supported and mostly ignored, however some tools will fail in some circumstances if they encounter them.
Just use packagename-0.* until it is out of alpha/beta (and then use packagename-1.*).
The problem here is twofold:
This method would not work for describing relase candidates which are post version 1.
Programmers from other ecosystems, such as that of rust, where it is quite common to have a stable library in 0.*, might wrongly assume that this library is stable. (Of course, it could be mitigated somewhat with a warning in the README, but I would prefer a better solution still.)
So, what is the best (and most conventional in haskell) way to indicate that the library version is in alpha/beta stage of development or is a release candidate?
As far as I know, there is not a package-wide way to say this. However, you can add a module description that describes the stability of the module to each of your modules' documentation.
{-|
Stability: experimental
-}
module PackageName.ModuleName where
I have a product that ships in two formats: individual packages and a combined single package. The single package is programmatically generated from the individual packages. The individual package semantic versions are manually determined and set.
How can I calculate a semantic version for the single package based on the semantic versions of each individual packages that respects the semantic versioning rules of the individual packages?
For discussion purposes, assume I have three individual packages:
a - 1.0.3
b - 2.1.0
c - 1.1.1
How would I calculate the single package's version?
If you want to create a unique version for each combination of three, the simplest way is to explicitly show each component:
a - 1.0.3
b - 2.1.0
c - 1.1.1
mainprog-a1.0.3-b2.1.0-c1.1.1
This helps you identify each individual component that make up the whole. That's a bit long, so alternative you could hash that:
sha256(a1.0.3-b2.1.0-c1.1.1)[1..10] = 6b5da1e87f
You'd want to store a table of each sum to the base components that made it, so you can easily look up the components. Either that or you could find a reversible hash algorithm to use instead.
You could of course just sum the numbers like in the other answer:
a - 1.0.3
b - 2.1.0
c - 1.1.1
result - (1+2+1).(0+1+1).(3+0+1)
result - 4.2.4
But here, it's ambiguous which three components made 4.2.4. You'd have to come up with some convoluted math formula to ensure individual versions would always add up to a 1-to-1 mapping to the final package version.
The numbers would become quite large, but one solution is to sum the individual components:
a - 1.0.3
b - 2.1.0
c - 1.1.1
result - (1+2+1).(0+1+1).(3+0+1)
result - 4.2.4
I'm trying to write a workaround because the versioning for package resources isn't possible with Puppet and Solaris 10.
What I need is the version string of an installed package.
I found out that factor already gathers this information, but sadly the info is stored in a nested array instead of a hash:
$facts['_puppet_inventory_1']['packages']
What's the easiest way to get the version string into a variable?
Thanks in advance.
What's the easiest way to get the version string into a variable?
If you care only about a small number of specific packages then you could write one or more custom facts that provide the version string of each one.
Alternatively, if you want to extract package version strings from the _puppet_inventory_1 fact you already have then you could write a custom function to do that job, or else use an inline ERB or EPP template.
Which is easiest depends on your skills and experience, but I suppose that for most people, the custom function would be the hardest of the alternatives I offered.
When you browse on the Internet and find paragraphs saying a version number followed by a dot (.) and ex (x), in programs usually. E.g. in Minecrat 1.8.x, or Apache 1.x.
It is called Semantic Versioning, and it's just a geeky way to display unspecific versioning (i.e. versions of a software/hardware). In semantic versioning (link above) the format is X.Y.Z (MAJOR.MINOR.PATCH).
Just like in math, each letter represents a variable. X is for a major version, Y for minors and Z for patches.
Let's take the Minecraft (a videogame) example: the game has a version of 1.8, and within this version they have patches (very small versions/changes), such as 1.8.8, 1.8.9, etc. If you're writing a paragraph and want to refer to all versions (patches) as long as they're from the major version 1.8, you can replace the formula X.Y.Z with 1.8.X.
Of course, you don't have to type it like that, since 1.8 will refer to all. Again, just a geeky way.
Some people don't follow the formula of X.Y.Z and simply enter the variable version/patch as Z, as in the Apache example, where it's 1.X instead of the correct way --acording to Semantic Versioning-- 1.Y.
I created a Perl script reading information from an XLSX sheet. Since on one machine it worked well, and on another it did not, I included a short debug section:
$sheetdate = ($sheet -> {Cells} [0] [$sheet->{MaxCol}]) -> value();
print "value: $sheetdate\n";
$sheetdate = ($sheet -> {Cells} [0] [$sheet->{MaxCol}]) -> get_format();
print "getformat: $sheetdate\n";
On one machine it printed:
value: 2016-01-18
getformat: yyyy-mm-dd
While on the other:
value: 1-18-16
getformat: m-d-yy
Same script, same worksheet, different results. I believe that something in the environment makes the difference, but I do not know what exactly.
Any hints?
"Same script, same worksheet, different results. I believe that something in the environment makes the difference, but I don not know what exactly."
You sort-of indicate here yourself that you're not really seeking the solution to a perl or XLSX problem so much as some assistance with troubleshooting your environment.
Without access to the environment its difficult to offer a solution per se, but I can say this - you need to;
1) Re-arrange things so that you do get the same result from both environments;
2) Identify a list of differences between the original, problem environment and the one that now "works"; and
3) Modify one thing on the list at a time - moving towards the environment that works - checking each time until it becomes clear what the key variable (not in a programming sense) is.
With regards to (1), take a look at Strawberry Perl. Using Strawberry, its relatively easy to set up what some call Perl on a stick (see Portable ZIP edition) - a complete perl environment on a USB stick. Put your document on the same USB and then try the two environments - this time with absolute certainty of having the same environment. If different results persist, try booting from a "live environement" DVD (linux or widows as appropriate), and then using the USB.
Ultimately, I'd suggest there's something (such as a spreadsheet template ) at play that is different between the environments. You just need to go through a process of elimination to find out what it is.
With the benefit of hindsight, I think its worth revisiting this to produce a succinct answer for those who come across this problem in the future.
The original question was how could a perl script produce two different results when the excel data file fed into it is identical (which was confirmed with MD5 checksums). As programmers, our focus tends to be on the scripts we write and the data that goes into them. What slips to the back of the mind is the myriad of ways that perl itself can be installed and configured.
The three things that should assist in determining where the difference between two installs lie are;
(1) Use strawberry perl on a stick as described above to take the environment out of the equation and thereby (if the problem "disappears") confirm that the problem is something to do with the environment.
(2) Use Data::Dumper liberally throughout to find where the flow of execution "forks."
(3) Compare the output of perl -V (note capital V) to find out if there are differences in how the respective perls were built and configured.
The root cause of the problem was an outdated Spreadsheet::XLSX cpan module installed as RPM from the distribution repository. The RPM included version 0.13 of this module, in CPAN there was already version 0.15, and since version 0.14 the module's behaviour was changed in this particular respect. So once I replaced the pre-compiled module with the version downloaded directly from CPAN and compiled locally, the problem was solved.