ENV variables for motoko builds

[Zane]

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.

[cryptoschindler]

@Zane

I’d still be out of luck cause the Motoko ICRC1 ledger is an actor class and requires init arguments.

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.

[Zane]

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.

[cryptoschindler]

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

[jamesbeadle]

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

[Zane]

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.

[marcpp]

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?

[ferMartz]

Does mops still work like this in version:
CLI 1.0.1
API 1.3

I tried but could not make work.

[ZenVoich]

@ferMartz thanks for bug report. Fixed in 1.1.2

[ferMartz]

@ZenVoich

See error below

[ZenVoich]

Do you see the error when building or is it only in vscode?

[ferMartz]

@ZenVoich see error and thanks for helping!!

[ZenVoich]

Fixed in mops cli 1.2.0

[ferMartz]

@ZenVoich It works perfect now!

Thanks

[ferMartz]

@ZenVoich the fix worked in local but once I deployed to prod the IS_PROD variable returns false all the time.