All software built in Conary is controlled through a recipe, which is essentially a Python module with several characteristics. Here is an example recipe, which has a typical complexity level:

The goal of Conary's recipe structure is not to make all packaging trivial, but to make it possible to write readable and maintainable complex recipes where necessary, while still keeping the great majority of recipes extremely simple—and above all, avoiding boilerplate that needs to be copied from recipe to recipe. This example is truly representative of the the most common class of recipes; the great majority of packaging tasks do not require any further knowledge of how recipes work. In other words, this example is representative, not simplistic. New packagers tend to find it easy to learn to write new Conary packages.

However, some programs are not designed for such easy packaging, and many packagers have become used to the extreme complexity required by some common packaging systems. This experience can lead to writing needlessly complex and thereby hard-to-maintain recipes. This, in turn, means that while reading the RPM spec file or Debian rules for building a package can be an easy way to find a resolution to a general packaging problem when you are writing a Conary recipe, trying to translate either of them word-by-word is likely to lead to a poor Conary package.

The internal structure of objects that underlie Conary recipes makes them scale gracefully from simple recipes (as in the example) to complex ones (the kernel recipe includes several independent Python classes that make it easier to manage the kernel configuration process). Some of the more complex recipe possibilities require a deeper structural understanding.

It is important to keep in mind that unlike RPM spec files and portage ebuild scripts (processed in read-eval-print loop style by a shell process) or Debian rules (processed by make), a Conary recipe is processed in two passes (three, if you count Python compiling the source into bytecode), because it both constrains the actions you can or should take and makes Conary more powerful. For example, you should not add sources inside a Python conditional (instead, you unconditionally add them but can choose not to apply them based on a conditional), but this constraint allows Conary to always automatically store copies of all sources that it has fetched by URL instead of being explicitly committed locally.

Another important data structure in a recipe is the macros object, an enhanced dictionary object that is an implicit part of every recipe. Almost every string used by any of the different kinds of objects in the recipe—including the strings stored in the macros object itself—is automatically evaluated relative to the contents of the macros object, meaning that standard Python string substitution is done. Thus, you do not have to type %r.macros after every string; the substitution is done within the functions you call. It also means that macros can reference each other. Be aware that changes to the macros object all take place before any list processing. This means that an assignment or change to the macros object at the end of the recipe will affect the use of the macros object at the beginning of the recipe. This is an initially non-obvious result of the multi-pass recipe processing.

The string items contained in the macros object are colloquially referred to by the Python syntax for interpolating dictionary items into a string. Thus, r.macros.foo is usually referred to as %(foo)s, because that is the way you normally see it used in a recipe.

The macros object contains a lot of immediately useful information, including the build directory (%(builddir)s), the destination directory (%(destdir)s) that is the proxy for the root directory (/) when the software is installed, many system paths (%(sysconfdir)s for /etc and %(bindir)s for /usr/bin), program names (%(cc)s), and arguments (%(cflags)s).