We were thinking about breaking up our application in smaller parts. However we have stopped the project due to this missing Feature/we couldn’t figure it out anyway.
Explanation of the problem
B → depends on A
C → depends on A
Now lets say dev1 builds a feature for B and dev2 builds a feature for C.
Both need to make small changes to A as well.
When working with dependencies you currently have two choices:
- Depend on a specific Version
- Depend on Published / Development
No. 1 Is a pain because they would need to make a lot of small versions and change them in the dependecy a lot.
No. 2 Does not work for more developers.
Make it possible to depend on a specific branch of the dependency.
This way it would be possible to develop a features by creating a feature branch in both apps, and after development merging it into the master.
If there are other workflows for developing dependencies with more than 4 developers.
I currently work around this by having a development copy of a dependency app. I can then use its master and published branches in the way you describe.
I use a singe local clone of the repo for the app. When I merge changes that are ready for production, I then push those to the production copy of the app.
e.g. for anvil-extras, I have two copies at anvil.works - one that is the production copy with the id that anyone can use, the other called ‘Anvil Extras Dev’ that only I can see. If I’m working on some new feature, I’ll test that using an app with the master branch of the dev copy as a dependency.
My local copy of the repo has three remotes - production, dev and github - we actually use a github action to push changes to production as and when we merge to main.
Elsewhere, for a larger team, we work in a similar fashion. Each of us has our own dev copy of the app we work on and we do our thing in there, sending pull requests to github when we’re ready. Amoni was built with this in mind to avoid even needing the dev copy at anvil and, instead, working entirely locally.
I would probably continue to work this way even if your request was implemented. It isolates the production copy nicely and reduces the risk of developers inadvertently making changes in the wrong place.
thanks for the workaround tipp, especially with github actions + amonia this seems to be a proper way to go! Provided, all your team members can properly use git - which at least in my experience is not always the case.
Still - I think as soon as Anvil will be used by larger Teams this feature will be a very nice addition.
But I agree that it is not as isolated as a local copy. Maybe this feature needs to come along with pull requests / branch protection to fully bring it to life.
Interesting. I regard git as core knowledge for anyone calling themselves a developer. I wouldn’t let anyone who didn’t know how to use it anywhere near the code base for anything other than personal hobby projects.
You can depend on specific version tags in the git repository. It’s not by branch, but it might provide a reasonable workaround.
You have to clone the repo to your local machine to create the tags, and push it back so Anvil recognizes them, but that gives you additional dependency points besides Production and Development.