I write a lot of native types for our internal use at work. (I tell people that if you are just using Exec in Puppet that ansible is one search away in Google. ) Some of the Puppet code used with these types would be very challenging to "pre-compile" in any way.
I think a lot of my questions are just because I don't consider a .pp file to usually be the unit of function in Puppet. I only consider the resource, which is usually implemented in Ruby, and everything else is dressing. Reading over this proposal raises questions about how it will fit into Puppet, a language and environment very different from Python, Java or other languages (Puppet 4 long leaving the domain-specific title by the wayside.) Since you have to build an AST on a node-by-node basis I am having a hard time telling the value of this verses something like a marker that indicates the code has been parser validated. If your code doesn't need node-by-node rebuild then perhaps the compiler could cache the results instead? I know the adage about about three hard problems in Computer Science still applies but what this is doing is creating and managing a cache. Pre-compiling is translating one language into another because compiling is changing one programing language, usually higher level, into another, usually lower level. Puppet does something very different in my understanding given above. It sounds as if the goat of the C++ parser is not to produce a catalog of resources but instead a ruby program for the agent to run. From the statements about a C++ Puppet parser is the target still just a collection of resources? Or is the goal to eventually spit out something other than what the Puppet server should send to a node? Is the scope just 'closed' .pp files? That is classes where all variables can be resolved without inquiry to facts? The behavior of languages that support things like pre-compiled files is specific to how they do binding of missing data. While this proposal punts on the 'serialization' format the handling of binding is pretty central. That raises questions like: How can a compiled format deal with Puppet features that call APIs? Is this for the defined types? How will it deal with the fact that the code could radically change based on node data not even present at the time the pre-compile is done? What happens if a precompiled module that depends on PuppetDB information is moved to an environment without it? For that matter, is the format intended to move between Puppet installations or just very similar ones? My model of Puppet is that the compiled catalog is just an ordered list of resources which do not have any placeholders like variables or sub-dividable parts. Classes in this model are just names that help you find the resources. This format is relevant to recent discussions among people on IRC and in the mailing lists and groups about getting and storing the catalog for a node. This is historically something hard as an end user. The context of any given resource is the whole catalog and at a minimum requires the dependent and depending classes in the graph tree. Otherwise how does this deal with the unresolved parts? On Wednesday, March 30, 2016 at 11:24:46 AM UTC-5, Eric Sorenson wrote: > > Hi, I've just posted a new Puppet RFC that describes pre-parsed and > pre-validated Puppet files, akin to '.pyc' files for Python. It's called > XPP and the doc is open for comments here: > > > https://docs.google.com/document/d/17SFn_2PJYcO5HjgA4R65a5ynR6_bng_Ak5W53KjM4F8/edit?usp=sharing > > Please comment inline on the doc, or come back to this thread if the > conversation gets too involved (more than about 4-5 replies in a comment > box on google docs becomes unwieldy) > > Once the commenting tapers off we'll incorporate changes into the spec and > post it as markdown in the puppet-rfc repo: > https://github.com/puppetlabs/puppet-rfc > > --eric0 > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/6e8b3ba1-e1a3-4008-9451-a4e0e65c5fcd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
