Anvil-provided __init__.py in pre-Package projects -- dare I touch this file?

Anvil Q&A
1

Some weeks back, when the new Package feature was in Beta, the IDE added an __init__.py file to my project:

#
# This repository is an Anvil app. Learn more at https://anvil.works/
# To run the server-side code on your own machine, run:
# pip install anvil-uplink
# python -m anvil.run_app_via_uplink YourAppPackageName

__path__ = [__path__[0]+"/server_code", __path__[0]+"/client_code"]

Anvil provided this file, and so I am as reluctant to tinker with it as I would with any of the .yaml files it provides. But if I want to run local tests, using my local copy of the app, then I might have to revise or remove this file. To prevent causing problems for others (and myself), I’d like to know what’s “safe” for me to do with this file, and what isn’t.

This app still follows pre-Package structure. I’d like to be able to run local tests of selected modules, with my local copy of the files, and my locally-defined Python Virtual Environment (v3.7.5 + Anvil + matplotlib + …).

Now, use of __init__.py turns the entire App into a Python Package. So if I add a testing framework to my Virtual Environment, or add a “main” program in the parent folder, these should be able to import application modules for testing purposes.

The trick is, many of these modules naturally import other modules. Files currently in folder server_modules are able to import modules from folder modules, when running on Anvil’s servers. In my local testing environment, they should be able to do the same, without editing the files themselves.

This should work, if I adjusted the above code to use App folders that actually exist (server_modules and modules), in place of the folders above.

But then, on my next git push, your Anvil server would see the revised __init__.py, and perhaps misbehave.

How should I proceed with this __init__.py file?

2

Hi @p.colbert,

That __init__.py shouldn’t have shown up in your non-package projects - that’s a bug!

That file is not currently a load-bearing part of the Anvil runtime, so you can change it safely, but you’ll want to change it back when you upgrade that app to packages.

3

That’s a real relief! Thanks, @meredydd!

I probably will upgrade it to Packages. Given its size, however, in files and megabytes, I’ll want to Package a smaller app, first, just to get a good feel for the new technique. Any time we have new options/requirements for where to put things and how to name things, it’s important to understand the forces at play, and how to resolve them, so that we can choose wisely.

In the meantime, it might be useful if I changed this file to reflect the current (old) folder structure. I suspect that will help with running various testing frameworks here.

While we’re on the subject of __init__.py in app folders, would it be worthwhile for me to put one in any of the other old-style folders? Or would that interfere with run-time operations?