Is there a way to spin up one local replica, and deploy many projects to it, each with their own dfx.json? So far I’ve always spun up one replica per project, where there is a dfx.json in the root of that project. dfx seems to expect this.
I’m writing some automated integration tests for canisters and it would be nice to only spin up one replica.
I think this “just works”. Or at least it did. I always have my local II in one project and every thing else in another. It works as long as I deploy in the right order. I just dfx start in one directory or the other…after that all coms go to the port so as long as it the replica is up it should “work”.
Yes, it “just works”. I tend to choose the most “finicky” project and start a replica in that folder, and then deploy my own projects from their respective folders, and that works for the most part. If in doubt, I nuke every .dfx folder, and retry. I had to do this weird ordering when dealing with II in the past, for example, but I’ve read that it’s gotten miles better in the new releases (both dfx and ii).
Okay I’ll try again, I thought I ran into issues with it so thought I’d get some insight.
If anyone working on the replica is reading this, I’d like to ask that some kind of configuration be made so that I can hard code what principle my specific instances get. This can be hell if you set up things a certain way and then try to onboard a developer that is just trying to learn the IC. Installing things in order is just added complexity that would be awesome to avoid.
I agree that would be a great feature, I often assume locally canister ids for users in my documentation, but that assumes dfx is installing things the same way every time.
I’ll second that this works, you can just use one project’s replica as your blockchain and deploy to that.
Related comment here:
We (cc @ericswanson) are working on a design for a global dfx instance and cache now, and we want to address these issues. I think that @skilesare and @lastmjs are right that reserving principals would be a really valuable feature, and it’s something that I hadn’t considered yet.
The main goals are:
dfx start and dfx stop from anywheredfx deploy (etc) from any project, or from multiple projectsdfx start –clean (from anywhere) followed by dfx deploy (from any project) works as expectedThe biggest design challenges are:
.dfx/local cacheOne (minor) problem I’m running into is how my Motoko canister and frontend client in dfx project A can call my Rust canister in dfx project B.
Right now, I have to copy the type files (i.e. .did.d.ts, .did.js, and .mo) created by running dfx generate in dfx project B into dfx project A, so that my Motoko canister and frontend client have the interface to interact with that Rust canister. I wonder if there is an easier way…
BTW, I’m not sure what use the .did Candid interface file is if I already have the language bindings in TS, JS, and Motoko…
We just wanted to expose that as a reference - you can disable it by configuring “bindings” and specifying which ones you actually need in the “declarations” config
Yeah that makes sense. I guess I was just curious when and how .did files are actually used.