If you ran into trouble while running this recipe, you can use David Tolney's cargo-expand (https://github.com/dtolnay/cargo-expand) to show you how the compiler expanded your proc_macros. It's a really useful tool to debug your macros, so be sure to check it out.

The reason behind the two-crate restriction is historical and only temporary. In the beginning, there was only one way to define macros, macro_rules!. People with exotic needs, who were ready to put in the effort, were (and still are) able to extend their programs by directly hooking into the Rust compiler itself. Crates written this way are called compiler plugins. Of course, this is incredibly unstable because every minor Rust release can break your plugin, but people kept on doing it because it gave them one big advantage, custom derives. The core team reacted to the increased demand for language extensibility by deciding to launch macros2.0 at some point in the future, bringing an overhaul to the entire macro system and many additional features, such as namespacing macros.

As they saw that most of the plugins were used only for custom derives, they also decided to bridge the time until macros2.0 with macros1.1, which are also called procedural macros. Stabilizing the small subset of the compiler that is needed to create custom derives. The only problem was that crates now had parts that ran normally and parts that ran at compile time instead. Mixing them proved difficult to implement and a bit chaotic, so the two-crate system of moving all procedural macro code into a -derive crate was created. This is the system used in this recipe, as at the time of writing, macros2.0 has not been stabilized yet. I encourage you to take a look at the current progress: https://github.com/rust-lang/rust/issues/39412.

If by the time you read this book, macros2.0 has been released, you should update your knowledge about how to write modern custom derives.