Actually, the dep ID is the correct thing to use! (It’s easy to get confused by older apps, which use the app ID as the dep ID.) Let me explain why, then I’ll get to the practical problem at the bottom, I promise!
Why dep_ids?
Anvil uses “dep IDs” to abstract out the identity of dependencies, so that the same app source code can depend on different apps in different circumstances.
For example, let’s imagine you want to contribute to anvil-extras. You fork the repo on GitHub, check out your fork into Anvil, create a new branch, and add a new feature to anvil-extras. Now you want to test it with one of your apps before you submit a pull request.
If your app’s source code were hard-wired to the app ID of the official anvil-extras instance, you’d be out of luck! But it actually uses an opaque dep ID in the source code, with a record in our database connecting that dep ID to the app ID. So you can go into your dependency config and remap that dependency: ie, point that dependency ID to your own development version of anvil-extras. Now your app will load your dev app, and you can play with your new features.
The dep IDs in your source code are unchanged: if you’re using GitHub to collaborate with someone else who’s using the official anvil-extras, their app will still load the official app, even though the source code is bit-for-bit identical to yours. This is because the connection between dep ID and app ID lives outside the source repository.
When you set dependency IDs in the App Server, it works the same way. The source code contains opaque dep IDs; your config needs to tell the App Server how map those dep IDs into directories where it can find other Anvil apps.
Backward compatibility, source of all my problems
It wasn’t always this way – when we first launched Anvil, apps referred to their dependencies by their app ID. Literally, if you used an anvil-extras component Slider on your form, the designer data (aka form YAML) would contain something like form:C6ZZPAPN4YYF5NVJ:Slider (where C6ZZPAPN4YYF5NVJ is the app ID of the “official” anvil-extras). This obviously didn’t work with the scenario above, so we invented the dep ID system instead.
But for apps that already existed, and had app IDs baked into their designer data, we just used the original app ID as the new dep ID. So if you took that old app and remapped it to point at your own development version of anvil-extras, the dep ID would still be C6ZZPAPN4YYF5NVJ. This works perfectly, but gets a bit confusing if you want to use the app server and need to get under the hood. Then you have to tangle with…all of this.
So what’s the actual problem here?
So, if that’s not @augustas.volbekas’s problem, what is? My guess is that @augustas.volbekas’s config file isn’t using the right dep IDs. To find the correct dep ID, open up anvil.yaml and look for the dependencies section. You should find the section for the M3 dependency, which contains a dep_id. Use that instead of dep_123 in your config file, and all will be well!