Best practices for apps & dependencies that include the same dependency

I just recently started using the excellent Input Box dependency from @stefano.menci (and by extension the Validator dependency). Both depend on Anvil Extras.

When developing I don’t mind depending on the Published version of Anvil Extras, but for the published version of any app I like to pin it to the last version of Anvil Extras I tested it with. That way any breaking changes in the dependency don’t break my published app. After I fix the issue and republish I can update the version the published app depends on, with no downtime to the users.

With an app and (at least) two of its dependencies all depending on Anvil Extras, I just discovered that the version they all depend on has to be the same.

What is everyone else doing for this situation?

What I’d planned was to have a Published and Development version of the dependencies, and pin the same version of Anvil Extras to the Published version as the published version of the app uses.

That seems reasonable enough, but I can envision having four or five apps depending on Input Box and Validator. Now I have to test all of the apps for compatibility with the latest version of Anvil Extras at the same time, and update the versions of all the apps and the dependencies in one go.

Is that just the way it needs to be, or am I missing something?

2 Likes

I’m having the same problem right now :frowning:

I set all the dependency chain to Development (or Published for Anvil Extras). This is fairly easy, especially today that the UI will tell you if and where there are dependency conflicts.

Then I set all the dependency chain back to Production (or last tested for Anvil Extra) before merging.

If you merge while some of the dependencies is not on its “standard” setting, you risk to break other apps. So I decided that “standard” is Published and I only set them to Development for the shortest time possible.


It used to be more difficult: About Development/Published dependency management

Now it is easier to get it right, because dependency conflicts are highlighted immediately after you change a version, but conflicts on apps you are not editing are not highlighted.


I think merging two branches should only be allowed if the result does not introduce errors: [Beta] Make sure apps don't break at time of merge because of different dependencies, or a big warning message should show the details of any changes.
… but I’m not sure it is even possible.


I asked for some controls on dependencies also here: Dependencies on Branches and Tags - #8 by stefano.menci

1 Like

Another thing to keep in mind to mitigate the dependency hell problem, is to NOT specify a dependency when it’s implied.

For example, if InputBox is a dependency, you don’t need to add Validator and Anvil Extras, so you have one fewer possible point of conflict.

This works just fine:

image

image

That’s definitely counter-intuitive for me, but you’re right, that would at least give a single spot where a particular dependency’s version is defined. Harder to find where that one spot is, but probably still easier than managing it in multiple places.

By that thinking, InputBox should be able to remove its dependency on Anvil Extras, right, since it depends on Validator and Validator includes Anvil Extras.

1 Like

Right… I just modified it.

So, using that technique (including common dependencies only in the lowest dependency in a chain that needs them), and tagging specific commits, I think I should be able to do the following:

  1. Test a dependency with a particular version of Anvil Extras*, and tag that commit with something meaningful.

  2. The higher level dependency can then depend on whichever tagged commit corresponds to the version of Anvil Extras that higher level dependency needs, and in turn can have its own tags for different versions of Anvil Extras.

  3. The main apps can then rely on specific tagged versions of dependencies based on which version of Anvil Extras each main app needs.

Upgrading to a newer version of Anvil Extras could be done in parts now, not all apps at once, since each can choose which tagged version of the dependencies to use. Dependencies can be upgraded to newer versions without affecting any apps that depend on them.

*Not picking on Anvil Extras, it’s just the dependency I use most often in every app. Any dependency could be named here.

To make it easier to use, and assuming Anvil Extras is the only external dependency with its own tagging system, you could use the same tags as in Avnil Extras, so you know what’s the minimum version of Anvil Extras any component or app is compatible with.

1 Like

Yeah, that’d been my thought, to make it obvious what version of Anvil Extras you were going to get. If there’s more than one dependency like that, the tagging system might get cumbersome, but it’d still be better if it were obvious which one you were going to get.