Handling anvil.yaml with Github integration

[jshaffstall]

What I’m trying to do:

Is there any way to not update anvil.yaml when integrating directly with Github? I’ve cloned a fork of an Anvil app, and thanks to needing to also clone its dependencies the anvil.yaml file has changed.

If I were to make changes to the app and submit a pull request those dependency changes would be part of the pull request, which I do not want.

What I’ve tried and what’s not working:

I’ve seen Owen’s technique here: Handling anvil.yaml in a git workflow that seems designed for when you’re going by way of a local git repo, not integrating directly with Github.

I also tried to see if there were some way on the Github side to ignore anvil.yaml when creating the pull request, but that doesn’t seem possible.

If necessary I can go by way of a local git repo, but I was hoping to use the built-in Github integration for convenience.

[yahiakalabs]

I’m also struggling with this with a collaborator on an open source app. Here’s what we have tried:

Gitignore

• Adding anvil.yaml to the .gitignore
• This does not work since you need to run an extra git command to actually stop tracking anvil.yaml, and you can’t do that in the Anvil Editor

Workaround 1 - Two sets of anvil.yaml

• Collaborator saves the anvil.yaml in a text file, makes all their configuration changes, commits them
• Right before they do a pull request (PR), they copy back the original anvil.yaml into their fork’s anvil.yaml. This keeps the PR clean, although there are extra commits in it.
• After the PR is accepted, they copy back their version of anvil.yaml so their app works again

Workaround 2 - Re-architect app as standalone dependency

• This is much more difficult. Treat your app as a dependency and re-architect it to avoid having any dependencies or special configurations
• Import the app as a dependency into your ‘publishing’ app. The ‘publishing app’ is basically a shell with the deployment, secrets, and other configs. Not a lot of actual code.

I’m not quite satisfied with either of these tbh.

Thoughts

• Collaboration on GitHub works well with dependency apps that don’t have their own dependencies. These apps have basically no special configurations.
• For most other types of apps (including dependencies that have their own non-public dependencies), the anvil.yaml being in the repo makes it really clunky to collaborate with the Anvil Editor.
• Looking at the open source version of anvil, and even amoni, both are set up with the understanding that configuration happens outside of the git repo.
• I think at the very least, there should be an option in the editor to override the anvil.yaml with one that is outside of the repo, and is treated like the app deployment options.

[jshaffstall]

Yeah, we ended up removing the non-third-party dependencies to make the collaboration work. It’d be nice if there were an option that had Github collaboration in mind.

[stucork]

Just to check how you updated dependencies when making changes.

Did you remove and re-add dependencies to the ones in your account?

You shouldn’t do this. Instead of removing and re-adding a dependency you should click the edit icon. This should keep the yaml representing the dependency config the same and update the dep_id to app in your account.

[yahiakalabs]

Ah I see - interesting quirk. Thanks!

I noticed another quirk. Changing the app name changes the app yaml and creates a commit, but reverting that commit doesn’t revert the app name.

Any similar tricks for SMTP settings?

[p.colbert]

I regularly use Git to back up my Anvil apps, and copy selected items from one to another. In this process, there are two things I’ve noticed with anvil.yaml

1. The .yaml files are often not very Git/diff-friendly. Line breaks and entire blocks can shift around, for no apparent reason. (To be fair, Embarcadero’s project files suffer from the same problem.) There is no “canonical” ordering that’s preserved. A proper diff needs to ignore those, and use structural diffing instead. Thus far, I haven’t found a simple tool for that.
2. The Wing IDE solved part of that. It separates the per-developer settings from the per-project settings. Each has its own file. Failing that, a reproducible ordering might make it easier for code to do that.

[stefano.menci]

@p.colbert

There is no “canonical” ordering that’s preserved.

I agree, I would love to have more consistency in the yaml formatting, so we don’t need to rely on diff tools to work around that problem.

@p.colbert

A proper diff needs to ignore those, and use structural diffing instead.

That’s what the IDE does in the UI diff (which doesn’t help in the context of this post). Sometimes with good results:

And sometimes not so good:

[p.colbert]

@stefano.menci

I would love to have more consistency in the yaml formatting

I think we may just have gotten our wish!

Sneaky Anvil Updates

I just did a git pull on my local copy of an app, and was surprised to see a huge number of changed files: all .yaml files. My Forms! My App was still running normally, even with these changes, but of course I had to look at the files. They’ve been alphabetized! That is, within the outline of objects-within-objects, each object’s attributes now appear in alphabetical order. Previously, they were in arbitrary order, which could change seemingly at random, making diffs very noisy and hard to …

And it’s not just the Forms. anvil.yaml has been sorted, too!

Thank you!

[meredydd]

Glad it’s being appreciated!

Apologies for the disruption - this does mean that the first time you edit an app, the .yaml files will all get normalised, but the previous ordering was not well-defined, and had started to “wander” in any case, so we bit the bullet and reordered every .yaml file in the hope of not having to do it again.

[p.colbert]

I’m very happy with this result. Yes, it was a surprise, but it didn’t break anything, and it makes several things a lot easier going forward.

Previously, if I needed to check what I changed in a .yaml file – did I do the right one? Did I catch all of them? – there was too much “noise” to trust a cursory diff or WinMerge run. A reliable result was hard. Now it’s easy!

Even a cursory reading of a file is improved. Easier to comprehend. Probably a bit safer to edit manually, too, on those rare occasions when one must.

Compare this to Embarcadero’s project files, which suffer from ALL of the problems you’ve eliminated, and from being XML. It’s no contest.