Taqueria Environments provide a powerful and flexible way to develop Tezos projects in multiple contexts. These environments can be used throughout the life cycle of a project from development to production.
To target an environment for a stateful task such as
taq originate, add the
--env flag with the name of the environment you would like to target. For example, to target an environment named
kathmandu_env for an origination, you would use the following command:
taq originate --env kathmandu_env
Environments are declared in
"label": "Local Tezos Sandbox"
The above example shows 3 environments:
Each environment has a type. The
development environment is
flextesa which uses the flextesa plugin for a local sandbox. The
production environments are both the
simple type which use only the rpcUrl.
Other environment types can be created with a plugin and it can define additional environment fields as needed.
The Default Environment
In the above example, the default environment is
development. For most taq commands the default environment will be used unless the
--env flag is provided.
Each environment also has a
Going back to the example
config.json above, it has three environments. So, each would have their own
These local config files are intended to store custom settings that are specific to a single developer's context.
For example, when deploying a contract to a sandbox or a test environment, the
config.local... file could contain the address of a contract deployed by a developer. Since each developer working on the same project would each have their own
config.local... file for each environment, they will have an isolated context when working.
config.local... files should be excluded from git commits, and are listed in the
.gitignore by default.
On the other hand, the main
config.json contains settings that belong to the project itself and should be shared by all developers working on that project since those settings are common.
Deploying and Transferring with Mainnet
Improvements are on the way. However, we currently only support signing in memory and we require a mnemonic to be written in the config file, so do not commit this file or delete the mnemonic before doing so. This is not the safest way to interact with mainnet so proceed with caution
accounts field to the
config.local.production.json file. For example:
"mnemonic": <12-24 words mnemonic generated via a wallet>
To interact with mainnet using
tempUser, users must include the
--env and the
--sender flags. E.g.
taq deploy counter --env production --sender tempUser