ENV variables for motoko builds

process.env.DFX_NETWORK only has 2 values atm as far as I know: ic and local and I wouldn’t mess with it too much cause other libraries work based on that assumption.

You can import actors using the “default” syntax even if they are actor classes, you just need to remove the init arguments from the candid file. You can create two did files, one public and one private one and then use a script to point to the public one, after you deployed the canister with the init arguments.

1 Like

Cool I didn’t know you could do that, but I really wish such a basic task wouldn’t require all these workarounds which one must first somehow discover by reading a thread and come with some amount of mental overhead, like in this case one would have to remember about the “hack” and update the private candid file everytime there are changes to the interface, not a problem if you work with a ledger, but if you interoperate with many canisters and they also happen to be updated often if gets annoying real quick.

2 Likes

i had a conversation with @claudio around that a couple of weeks back, maybe he can provide some insights?

Hey @Zane,

A year on just wondering if this is still the best way to implement environment variables within motoko?

For example I have checks in my backend canister sns generic function endpoints to make sure the caller is the SNS governance canister, that canister id would be an environment in motoko.

Any info appreciated,
James

Afaik it is. For canister id checks you could also consider using the (now not so) new dfx feature which allows to force specific canister ids on local net.By doing so you can simply set the local SNS governance canister to have the same id as it does on mainnet and avoid the need of tying it to your environment entirely.

3 Likes

Thanks. Is this the feature you’re talking about? It seems only possible to force remote canister ids, not local. Maybe you’re talking about another feature?