1. Add XRD as a defined resource.

Enter the arguments for the first function call example: PackageName new 200,$tokenEMT 200,$tokenGMT No ticks, qoutes or backticks

2. Should the 1st line above read "Enter blueprint name and function-call"?
3. Is the example correct? When I copy and paste the example and change the token names it still prints the example token names.
4. quotes is misspelled.
5. Change the first account created name from "account" to "accout1", same with pubkey.

The README needs some more details about building and using revup.

(We shouldn't presume that scrypto programmers know how to build and use rust command line tools.)

new-account command didn't print "New Entities" anymore in scrypto 0.3. adding an edge case using "A new account has been created!"

Extend revup's -r option by adding an extra option that enables reading from stdin.

Assuming that option is -s then with this in place is should be possible to add:

#!revup -rs -

at the beginning of a rev file and then make it executabe.

Obviously revup needs to ignore #! lines since you would want such a rev file to be usable in the normal way too.

(This enhancement was suggested by devmannic.)

Improve the installation process by making revup available as a crate.

Probably want to wait until after Alexandria for this task as revup may need to go though some adjustments at that time.

A string argument like that for a token description like this:

"my token description"

is not handled correctly by the "-r" (aka --rev") option leading to a resim failure. (Not sure about the json version either.)

Furthermore it seems like an extra space is creeping into most or all of the arguments.

The second account and two token supply commands should be handled as the default set of optional commands. These optional commands should be overridable (perhaps using a file in the current directory.) A way to make the override file should be defined and implemented.

When running revup if the $package env variable is already set to something besides what the next publish yields, then an error is encountered when trying to run the first call-function after publish . is run.

The workaround is to source .env and then simply run revup again.

Fixing this so that it works 100% of the time may require a rethink of the revup workflow.

Closes #21

NOTE: for deployments to work a crates.io API token must be generated and added to the CI secrets (CARGO_TOKEN)

This is a basic implementation that does the minimum required to publish the crate.

Workflow

• All PRs and merges to the develop branch cause the workflow to run: checking out the project, building it and running any tests
• Pushing a new tag (for example v0.2.1 will run the workflow and additionally publish the crate to crates.io
• After publishing a new release can be created via Github

Future Improvements

• Additional badges on the readme
• Auto publish documentation
• Linting (cargo clippy)
• Formatting (cargo fmt)
• Auto release management (Github Action generates a release after publish)
• Changelogs

Adds new --rev (-r) option to read in and process resim commands from a human readable and editable file.

Supports the same magic for setting environment variables as we go.

Refactors the code a bit especially in run_cmd() so that run_file() shares much of the same logic as the new run_rev().

Handles the special case addition of adding tokenXRD in a smarter way (specifically add it after "reset" command is called.)

To make it easier for more people to get involved with the design, maintenance and evolution of revup, the repo was transferred from initial author dRAT3 to the RadGuild organization.

The "append_env" function tries to write to these files but does not pass the create flag in order to ensure they get created if they're missing. W/o the create flag, if those files are missing, you get a cryptic Critical error, aborting The system cannot find the file specified. (os error 2)

To remedy this, simply modify the file open options to add the create flag like so: let mut env_file = std::fs::OpenOptions::new().create(true).append(true).open("env.bat")?;

When working with *.rev files, revup processes all instructions in a file one after the other. If one instruction fails, revup continues to process the subsequent instructions anyway. This may be desirable in some cases, but in others you may want processing to stop there.

If revup supported a switch like e.g. set -e in bash, a user could configure revup's behavior as desired.

This is an extension to issue #24. A number of future improvements were identified as part of that issue:

• [ ] Additional badges on the readme
• [ ] Auto publish documentation
• [ ] Linting (cargo clippy)
• [ ] Formatting (cargo fmt)
• [ ] Auto release management (Github Action generates a release after publish)
• [ ] Changelogs
• [ ] Matrix testing strategy (test on Mac/Windows too)

Add support for .rev files into VS Studio and/or other smart editors.

This mostly boils down to helping guide the selection and creation of supported resim commands.

A file showing examples of all of the supported resim commands would be handy.

(We can also point out which resim commands don't work well and/or need an update to include special handling by revup.)

A GUI should be developed to frontend the --rev option.

Several possibilities exist:

• A GUI app for the desktop.
• A browser-based app for desktop and, eventually, mobile.
• An extension to an editor that understands resim could work.