Rename more things

Cargo.toml

@@ -1,8 +1,8 @@
 [workspace]
 members = [
-    "con",
+    "dylo",
+    "dylo-cli",
     "dylo-runtime",
-    "con-loader", "test-workspace/app",
 ]
 exclude = [
     "test-workspace",

README.md

@@ -19,6 +19,8 @@ for annotations from the [dylo](https://crates.io/crates/dylo) proc-macro crate,
 Although that pattern is doable by hand, dylo takes a lot of the human error and repetitive work
 out of the equation.
 
-  * [dylo-runtime](https://crates.io/crates/dylo-runtime)
+To learn more, read the various crate documentation in order:
+
   * [dylo](https://crates.io/crates/dylo)
+  * [dylo-cli](https://crates.io/crates/dylo-cli)
   * [dylo-runtime](https://crates.io/crates/dylo-runtime)

dylo-runtime/README.md

@@ -1,26 +1,26 @@
 [![license: MIT/Apache-2.0](https://img.shields.io/badge/license-MIT%2FApache--2.0-blue.svg)](LICENSE-MIT)
-[![crates.io](https://img.shields.io/crates/v/con-loader.svg)](https://crates.io/crates/dylo-loader)
-[![docs.rs](https://docs.rs/dylo-loader/badge.svg)](https://docs.rs/dylo-loader)
+[![crates.io](https://img.shields.io/crates/v/dylo-runtime.svg)](https://crates.io/crates/dylo-runtime)
+[![docs.rs](https://docs.rs/dylo-runtime/badge.svg)](https://docs.rs/dylo-runtime)
 
-# con-loader
+# dylo-runtime
 
-`con-loader` provides supporting code for the `con` crate, handling module building and loading on MacOS and Linux. End users shouldn't need to use this crate directly - it exists as a dependency of the `con` crate and crates generated by the [dylo-runtime](https://crates.io/crates/dylo-runtime) tool.
+`dylo-runtime` provides supporting code for the `con` crate, handling module building and loading on MacOS and Linux. End users shouldn't need to use this crate directly - it exists as a dependency of the `con` crate and crates generated by the [dylo-runtime](https://crates.io/crates/dylo-runtime) tool.
 
 However, this is the right place to learn about environment variables that will impact the
-behavior of con-loader at runtime:
+behavior of dylo-runtime:
 
-* `CON_TARGET_DIR`: Set the build directory for hot-reloadable plugins. By default, plugins are built into `$HOME/.con-mods/{mod-name}` or `%USERPROFILE%\.con-mods\{mod-name}` on Windows.
+* `DYLO_TARGET_DIR`: Set the build directory for hot-reloadable plugins. By default, plugins are built into `$HOME/.con-mods/{mod-name}` or `%USERPROFILE%\.con-mods\{mod-name}` on Windows.
 
-* `CON_BUILD`: Set to "0" to disable automatic mod compilation. Defaults to "1".
+* `DYLO_BUILD`: Set to "0" to disable automatic mod compilation. Defaults to "1".
+  Set to "verbose" to have cargo inherit stdout/stderr, which will show progress messages
+  and colors.
 
-* `CON_NOISY_BUILDS`: Set to "1" to pipe build output directly to stdout/stderr. By default, output is only shown if the build fails.
-
-In production, you probably want `CON_AUTOMATIC_MOD_BUILD` to be set to zero, as your mods
+In production, you probably want `DYLO_BUILD` to be set to 0, as your mods
 should be pre-built, and put in the right place, next to the executable.
 
 > **Warning**
 > Make sure to build your mods with the `rubicon/import-globals` and `impl`
-> features enabled, just like `con-loader` would do.
+> features enabled, just like `dylo-runtime` would do.
 >
 > See the [rubicon docs](https://crates.io/crates/rubicon) for more details: essentially, your
 > mods need to refer to the same process-local and thread-local variables that your main app does,
@@ -41,7 +41,7 @@ workspace/
     src/lib.rs etc.
 ```
 
-Then `con-loader` expects a file hierarchy like this:
+Then `dylo-runtime` expects a file hierarchy like this:
 
 ```
 workspace/
@@ -57,9 +57,8 @@ in a container image under `/app` or whatever.
 
 ## ABI Safety
 
-con-loader uses [rubicon](https://github.com/bearcove/rubicon) to ensure that the ABI of the
-module matches the ABI of the app they're being loaded into — this is not the concern of the
-"con" family of crates however.
+dylo uses [rubicon](https://github.com/bearcove/rubicon) to ensure that the ABI of the
+module matches the ABI of the app they're being loaded into.
 
 If you mess something up, you should get a detailed panic with colors and emojis explaining
 exactly what you got wrong.

dylo-runtime/src/details/platform.rs

@@ -20,7 +20,7 @@ impl Extensions {
                     dbg: "so.dwp",
                 }
             } else {
-                panic!("Unsupported operating system - https://crates.io/crates/dylo-loader only supports MacOS and Linux for now");
+                panic!("Unsupported operating system - https://github.com/bearcove/dylo only supports MacOS and Linux for now");
             }
         });
 

dylo/Cargo.toml

@@ -1,5 +1,5 @@
 [package]
-name = "con"
+name = "dylo"
 version = "1.0.0"
 edition = "2021"
 authors = ["Amos Wenger <[email protected]>"]

dylo/README.md

@@ -2,15 +2,17 @@
 [![crates.io](https://img.shields.io/crates/v/con.svg)](https://crates.io/crates/dylo)
 [![docs.rs](https://docs.rs/dylo/badge.svg)](https://docs.rs/dylo)
 
-# con
+# dylo
 
-`con` provides attribute macros like `#[dylo::export]` used to mark trait implementations that should have corresponding trait definitions generated in consumer crates.
+`dylo` provides the `#[dylo::export]` attribute.
 
-This crate has zero dependencies and does not perform any token transformations - it simply provides the attribute definitions that the `dylo-runtime` tool looks for when generating consumer crates.
+This crate has zero dependencies and does not perform any code generation of its own - it simply
+provides the attribute definitions that the [dylo-cli](https://crates.io/crates/dylo-cli) tool looks
+for when generating consumer crates.
 
 ## Usage
 
-Slap `#[dylo::export]` on impl blocks whose trait you want `dylo-runtime` to genaerte:
+Slap `#[dylo::export]` on impl blocks whose trait you want `dylo-cli` to genaerte:
 
 ```rust
 #[dylo::export]
@@ -26,7 +28,7 @@ impl Mod for ModImpl {
 > Only dyn-compatible traits can be marked with `#[dylo::export]` — dynamic dispatch
 > is kinda the whole point.
 
-Traits generated by `con` are `Send + Sync + 'static` by default. If you need a trait to be
+Traits generated by `dylo` are `Send + Sync + 'static` by default. If you need a trait to be
 not sync, you can pass `nonsync` as an arugment to `dylo::export`:
 
 ```rust
@@ -46,10 +48,10 @@ impl Bar for BarImpl {}
 The `Mod` trait has special treatment: the concrete type `ModImpl` must implement `Default`,
 because it must be able to be constructed dynamically when the mod is loaded, from no arguments.
 
-`dylo-runtime` will make sure that:
+[dylo-cli](https://crates.io/crates/dylo-cli) will make sure that:
 
   * In the `mod` crate, there's an exported function that returns a `Box<dyn ModImpl>`
-  * In the `con` crate, there is code (leveraging [con-loader](https://crates.io/crates/dylo-loader))
+  * In the "consumer" crate, there is code (leveraging [dylo-runtime](https://crates.io/crates/dylo-runtime))
     that knows how to build, load, and return a `Box<dyn Mod>`.
 
 If you need your initialization to take arguments, you can simply export two interfaces:
@@ -77,22 +79,34 @@ impl Client for ClientImpl {
 }
 ```
 
+Note that you're not supposed to write the `trait` definition yourself — just the
+`impl Blah for BlahImpl` block. It's [dylo-cli](https://crates.io/crates/dylo-cli)'s job
+to generate the trait for you.
+
+In concrete terms, it will add an `src/.dylo/spec.rs` file to your original crate, and
+add an `include!(".dylo/spec.rs")` item to your `src/lib.rs`
+
+> **Warning**:
+>
+> Other crate structures exist but aren't supported for now.
+
 ## Dependencies
 
-Because the `con-XXX` crate is generated from the `mod-XXX` crate, it shares some dependencies
+Because the consumer crate is generated from the `mod-XXX` crate, it shares some dependencies
 with it: any types that appear in the public API must be available to the `con-XXX` crate as well.
 
 However, some types and functions and third-party crates are only used in the implemention. Those
 can be feature-gated both in the `Cargo.toml` manifest:
 
 ```toml
 [package]
-name = "mod-clap"
+name = "mod-cliargs"
 version = "0.1.0"
 edition = "2021"
 
 [lib]
-# this is important for mods — the `con-` version of this crate will be a "rlib"
+# mods are always cdylibs — this one will build into
+# `target/debug/libmod_cliargs.so` or `target/debug/libmod_cliargs.dylib` on macOS.
 crate-type = ["cdylib"]
 
 [dependencies]
@@ -131,13 +145,13 @@ impl Mod for ModImpl {
 }
 ```
 
-In the `con` version of the crate, only the non-impl dependencies and items will remain:
+In the consumer version of the crate, only the non-impl dependencies and items will remain:
 
 ```toml
-# rough outline of what `dylo-runtime` would generate for this `con-clap` crate
+# rough outline of what `dylo-runtime` would generate for the consumer `cliargs` crate
 
 [package]
-name = "con-clap"
+name = "cliargs"
 version = "0.1.0"
 edition = "2021"
 
@@ -165,7 +179,7 @@ attributes, then formatting the AST with rustfmt.
 
 ## Limitations
 
-con will expect all your exported traits to be [`dyn`](https://doc.rust-lang.org/std/keyword.dyn.html)-compatible (this used to be call "object safe")
+dylo will expect all your exported traits to be [`dyn`](https://doc.rust-lang.org/std/keyword.dyn.html)-compatible (this used to be call "object safe")
 
 Here's a list of things you cannot do.
 
@@ -285,7 +299,7 @@ impl Client for HttpClient {
 
 Support for `dyn-compatible` async fn in traits is in the cards afaict, see the
 [dynosaur](https://crates.io/crates/dynosaur) crate for a peek into the future (however you
-cannot use it with con).
+cannot use it with dylo).
 
 ### Self type restrictions
 
@@ -318,12 +332,12 @@ impl Builder for RequestBuilder {
 Essentially, as a consumer, we don't know the size of "Self" — so we need the indirection.
 References (`&self`, `&mut self`) are always fine.
 
-## Should `con` exist?
+## Should `dylo` exist?
 
 Not really — much like [rubicon](https://github.com/bearcove/rubicon), all that
 should be possible in stable Rust, with support from the compiler, etc.
 
-Half the reason to bother with an approach like con's is to avoid unnecessary
+Half the reason to bother with an approach like dylo's is to avoid unnecessary
 rebuilds. The _proper_ approach for that is being explored by other folks, see:
 
   * [Downstream dependencies of a crate are rebuilt despite the changes not being public-facing #14604](https://github.com/rust-lang/cargo/issues/14604)