reci.py's Introduction

RECI.PY

Reci.py is a build system. It is focused on describing the file tree as it should be after the build. Build files are XML:

<folder name="dist" xmlns="http://recipy.hoverview.org/default">
  <zipfile filename="myapp.war">
    <folder name="WEB-INF">
      <copies of="src/main/webapp/web.xml"/>
    </folder>
  </zipfile>
</folder>

This approach is meant to give a clear view of build results with a lot of flexibility at low complexity. The default xml namespace handles things like creating a folder and copying static files there. Other namespaces can be used by installing (with git clone or other mechanism) a vocabulary module into the vocab lib folder in the reci.py installation. Vocabularies are Python modules that follow a simple set of conventions.

reci.py's People

Contributors

Watchers

reci.py's Issues

There should be a howto for writing new vocabs

"zipped" directive

Subrealize into a tmp folder, then zip them into its own dir.

There is another project called recipy now at github, with more traction. Should we rename?

Take another look at merging the reci_* files into one module.

Perhaps this requires a move away from the generic realizer model. Is it worth it?

There should be usage sections and examples in the readme

Add a vocab called "Local", mapping directive names to local scripts

Add a Vocab that registers http://recipy.hoverview.org/local and implements all directives by running local files.

Is this possible? Or do the vocabs iterate possible directives? Should be possible anyway.

When realizing an element <local:bob some="attr"/>
Assume a path within the project tree and a path within the recipy distribution, these are searched for an executable bob_wrapper or something. This is invoked with a param
some=attr in the folder where the directive should be realized.