Description

cargo binrw run panics when $CARGO_MANIFEST_DIR isn't an environment variable

Expected Behavior

I thought cargo run, and extensions to it, would populate this env variable at runtime. It appears this does not happen.
The current workaround is:

$ CARGO_MANIFEST_DIR='/home/david/code/rust/cargo-binrw' cargo binrw run
===============================================================================================
-------------------------------------------B I N R W-------------------------------------------
===============================================================================================
 
Spawning the tracing server at:
HOST:    tcp://127.0.0.1
PORT:    31958
PROJECT: Some("/home/david/code/rust/cargo-binrw")

My initial draft for the cargo-binrw file format is to leverage Ron and (for now) support only a single logging server with the following configurable properties:

• project
• host
• port
• editor_host
• editor_port
• silent_foreground
• logging

If Ron is acceptable, I think it could look like:

Binrw([
    (
        project: my_project,
        host: "127.0.0.1"
        port: 42069,
        editor_host: "127.0.0.1",
        editor_port: 42070,
        silent_foreground: false,
        logging: Logging(
            enabled: false
            output_file: "$CARGO_MANIFEST_DIR/binrw.log",
            mode: 'a'
        ),
    ),
])

The following items are conditionally considered "in scope" for phase 1:

cargo binrw new

CLI handling is broken down into the following cases:

• 0x0 — cargo binrw new:

Since no project name is specified, this command will check if the environment contains a $CARGO_MANIFEST_DIR. If it's not found, we advise the user: "Could not detect a local Rust project. Please run cargo new before continuing."

• 0x1 — cargo binrw new my-binrw-project

The user declared a project. This command will check if another project already exists in CARGO_MANIFEST_DIR, and informs the user if a project cannot be created: followed by an exit. If it can, this command creates "binrw.toml" under the manifest directory.

• 0x2 — cargo binrw new .

(See above, but factor in the globbing "." to imply the current working directory")

cargo binrw & cargo binrw run

cargo binrw is an alias, or shorthand, for expressing the full command cargo binrw run. Its handling should be intelligent, or at the very least follow some heuristics I've laid out in src/lib.rs.

• 0x3 — cargo binrw run [explicit options]

cargo binrw can support the following extra arguments to customize the process. These settings directly override anything in $CARGO_MANIFEST_DIR/binrw.toml. If the validation fails, inform the user and exit. Otherwise, run the server.

cargo binrw run \
  --host (^(?=.{1,255}$)[0-9A-Za-z](?:(?:[0-9A-Za-z]|-){0,61}[0-9A-Za-z])?(?:\.[0-9A-Za-z](?:(?:[0-9A-Za-z]|-){0,61}[0-9A-Za-z])?)*\.?$) \
  --port ([0-9]{2,5}) \
  --project (([(A-Za-z]|[\-|_|^\s])+) \
  --log (.*) \
  --silent <see below>

I definitely messed up this regex ^ somewhere; please help us correct it if you find an error

• 0x4 — cargo binrw run --host 0.0.0.0 --port 8000 --project my-binrw-project -- [extra]

Since additional arguments may be passed after the provisioned structopt arguments, [extra] is collected from std::env::args() starting at the 3rd index (4th slot) (( I think )).

• 0x5 —cargo binrw run

Use the values in $CARGO_MANIFEST_DIR/binrw.toml to update the runtime configuration. If the file does not exist, tell the user to run cargo binrw new use the default values for everything, and do not worry if a project exists or not.

- [ ] 0x6 — cargo binrw run --silent(-foreground[=[true|false]]?)
> This one's tricky, but to support scripting/automation-testing, we can't hold STDOUT/STDERR hostage so one option is to spawn a TTY connection and feed it like you would a named pipe. The implementation must make an airtight case that this will be fully-closed at the end of the session.

• 0x7 — cargo binrw run --logging ([true|false])

Tee all output to the log file indicated, otherwise treat the /target/binrw.log. Treat default behavior as appending to this file, else we risk burning someone's beloved log.

Babystep 0x01

Part 1

Invoking cargo binrw spawns a tracing server.

Specifically, this needs to accomplish a couple distinct steps:

• Depending on the crate type (lib or bin), we invoke cargo <run | test | whatever> and if compilation errors occur on structs tagged with binrw traits, we take note of those, and pipe the output to stderr.
• ...
• ...
• ...

Part 2

Buffering the messages to something either in a temporary file (my preference, because we can just tell the editor -- hey read this file -- and we don't have to do anything tricky with memory), or maybe just expose an extern file_descriptor address.

Specifically, we need to accomplish:

• ....
• ...
• ...

Part 3

TBD

@jam1garner do you mind making a pretty document with all of the ideas we've discussed into one central spot? I think this could include the MS paint markup you did the other night, and the steps from whatever you think is important to newcomers.