Refactor again

[LPGhatguy]

This PR implements the changes that we've thought about and talked about in meatspace for awhile.

Traits

• Preserves the many-to-many relation between inputs and outputs established in #1.
• Merges the tarmac.toml (InputConfig) and tarmac-project.toml (ProjectConfig) file distinction in favor of tarmac.toml being an object named Config.
• Enables including configs inside eachother instead of using groups.
• Enables listing "input rules" in the config file, each containing a glob and the same configuration values that were previously in InputConfig.

Intended Usage

After this refactor, we have a fairly clear story for how Tarmac is intended to be used by application-style projects (games, Studio plugins) as opposed to library projects.

Games and Studio Plugins

These projects should have one top-level tarmac.toml file. If using Rotriever or another package manager like npm, it should contain the folder where dependencies are located in the includes list:

name = "My Cool New Game"

# we target the original iPhone, so we need smaller spritesheets
max-spritesheet-size = [512, 512]

# Rotriever packages are in the "Packages" folder
# npm's packages are in the "node_modules" folder
[[includes]]
path = "Packages"

# All of our game's UI assets should be packed into spritesheets
[[inputs]]
glob = "assets/ui/**/*.*"
codegen = "url-and-slice"
packable = true

# All of our other images can be uploaded as-is
[[inputs]]
glob = "assets/textures/**/*.*"
codegen = "url"
packable = false

To upload all of the game's assets and then build its place file, we'd expect users to run:

tarmac sync --target roblox
rojo build -o CoolNewGame.rbxlx

Libraries

Libraries should have two Tarmac config files. One named tarmac.toml file that's used when the library is being used as a dependency, and one named something like test.tarmac.toml that's used when testing the library itself that includes the former.

This setup parallels common practice with Rojo. Many libraries have a default.project.json that defines just the library, as well as a test.project.json file that's used for testing the library.

If using a package manager like Rotriever or npm, tarmac.toml should not include folder where packages are installed, as it will not exist when used as a dependency in either package manager:

name = "Yoact"

# Define that our assets can be packed into spritesheets.
[[inputs]]
glob = "assets/**/*.*"
codegen = "url-and-slice"
packable = true

The library's test.tarmac.toml file, however, should include the folder where packages are installed. It should also include the library's root config in order to avoid needing to duplicate that information.

name = "Yoact Test Place"

# Include our main Tarmac config so that we get all our normal assets
[[includes]]
path = "."

# Include our Rotriever dependencies
[[includes]]
path = "Packages"

# We may or may not have additional inputs for the test place.
# Here, we don't.

To generate all of the assets for the test place, put them into Studio's content folder, then build the test place with Rojo, we would expect the user to run:

tarmac sync --target content test.tarmac.toml
rojo build test.project.json -o TestPlace.rbxlx

If the library author wants to build a standalone model file for the library, referencing assets from their account (or maybe a group that is publishing the model), we would expect them to run:

tarmac sync --target roblox
rojo build -o Yoact.rbxm

The generated Yoact.rbxm would contain references to the uploaded assets. If those assets are public and usable from any game (ie they are not animations), this model would work when placed in any game.

If the library wanted to publish this library to a package repository, the library author would also have the option doing an upload before publishing the library:

tarmac sync --target roblox
npm publish # or rotrieve publish

In this scenario, users of the library that don't use Tarmac would still get all of the project's assets as long as they're public assets that are usable by all games. Some asset types, like animations, are not publicly usable.

If a user of the library does use Tarmac, then the next time they run tarmac sync after installing with their package manager, Tarmac will overwrite the generated modules with newly-uploaded assets if necessary. This would happen if the already-uploaded assets aren't public, they've changed on disk, have been moderated on roblox.com, need to be packed into spritesheets, etc.

To Do

• [x] Reimplement basic structure of sync.rs
• [x] Nail down and document the structure more thoroughly

[LPGhatguy]

I think we're ready to merge this and start working out of master. What do you think?