On 2013-28-08 19:19, Andy Parker wrote:

What I'm thinking (in terms of a workflow a user might perform):

   # produce a fully validated AST serialization
   $ puppet manifest compile --manifest site.pp --modulepath
~/modules:/etc/puppet/modules --output my-puppet-code.ast
   # load that validated AST as a particular environment into the
master. The master would swap in the new code for that environment only
at the start of a new compile, any existing compiles using the old code
loaded for the environment would continue unchanged.
   $ puppet master load --pic my-puppet-code.pic --environment staging
This is just an example of how it could be split up into multiple
commands. This could also be done at the beginning of the catalog
request instead of by the user.

At the moment, I'm ignoring any data that would need to go along with
this. Taking that into account might change things as separate commands.


Basically this is a copy of the AST into another form that then has to be loaded (which means some form of parsing and resurrection of the data). If so, Ruby marshal of the AST will be the fastest. I think we can allow this to be both a user level command "compile" as well as "on demand" (a check is made at transaction start that source has not changed, if so it can be compiled on the fly).

I think it is safe to use Ruby marshal since the data is for a specific runtime and it is completely managed by this runtime.

If we instead want off-line compilation and have sharing of bundles (i.e. 'jar-like' things), Ruby Marshal is out of the question, and I then doubt that a serialized AST is much faster to load than parsing the language, but it depends to a large degree on the complexity of difficult to lex/parse constructs (gazillions of interpolation expressions).

A jar-like approach would mean that only the timestamp of the jar needs to be checked, then reading its manifest in order to know its content.

- henrik


--
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 post to this group, send email to puppet-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to