<p>While this is fine for small applications, for larger applications
it’s a good idea to use a package instead of a module.
The <aclass="reference internal"href="../tutorial/index.html"><spanclass="doc">Tutorial</span></a> is structured to use the package pattern,
see the <aclass="reference external"href="https://github.com/pallets/flask/tree/main/examples/tutorial">example code</a>.</p>
<sectionid="simple-packages">
<h2>Simple Packages<aclass="headerlink"href="#simple-packages"title="Link to this heading">¶</a></h2>
<p>To convert that into a larger one, just create a new folder
<codeclass="file docutils literal notranslate"><spanclass="pre">yourapplication</span></code> inside the existing one and move everything below it.
Then rename <codeclass="file docutils literal notranslate"><spanclass="pre">yourapplication.py</span></code> to <codeclass="file docutils literal notranslate"><spanclass="pre">__init__.py</span></code>. (Make sure to delete
all <codeclass="docutils literal notranslate"><spanclass="pre">.pyc</span></code> files first, otherwise things would most likely break)</p>
<p>You should then end up with something like that:</p>
<p>But how do you run your application now? The naive <codeclass="docutils literal notranslate"><spanclass="pre">python</span>
<spanclass="pre">yourapplication/__init__.py</span></code> will not work. Let’s just say that Python
does not want modules in packages to be the startup file. But that is not
a big problem, just add a new file called <codeclass="file docutils literal notranslate"><spanclass="pre">pyproject.toml</span></code> next to the inner
<codeclass="file docutils literal notranslate"><spanclass="pre">yourapplication</span></code> folder with the following contents:</p>
<p>What did we gain from this? Now we can restructure the application a bit
into multiple modules. The only thing you have to remember is the
following quick checklist:</p>
<olclass="arabic simple">
<li><p>the <codeclass="code docutils literal notranslate"><spanclass="pre">Flask</span></code> application object creation has to be in the
<codeclass="file docutils literal notranslate"><spanclass="pre">__init__.py</span></code> file. That way each module can import it safely and the
<codeclass="code docutils literal notranslate"><spanclass="pre">__name__</span></code> variable will resolve to the correct package.</p></li>
<li><p>all the view functions (the ones with a <aclass="reference internal"href="../api.html#flask.Flask.route"title="flask.Flask.route"><codeclass="xref py py-meth docutils literal notranslate"><spanclass="pre">route()</span></code></a>
decorator on top) have to be imported in the <codeclass="file docutils literal notranslate"><spanclass="pre">__init__.py</span></code> file.
Not the object itself, but the module it is in. Import the view module
<strong>after the application object is created</strong>.</p></li>
</ol>
<p>Here’s an example <codeclass="file docutils literal notranslate"><spanclass="pre">__init__.py</span></code>:</p>
<p>Every Python programmer hates them, and yet we just added some:
circular imports (That’s when two modules depend on each other. In this
case <codeclass="file docutils literal notranslate"><spanclass="pre">views.py</span></code> depends on <codeclass="file docutils literal notranslate"><spanclass="pre">__init__.py</span></code>). Be advised that this is a
bad idea in general but here it is actually fine. The reason for this is
that we are not actually using the views in <codeclass="file docutils literal notranslate"><spanclass="pre">__init__.py</span></code> and just
ensuring the module is imported and we are doing that at the bottom of
the file.</p>
</div>
</section>
<sectionid="working-with-blueprints">
<h2>Working with Blueprints<aclass="headerlink"href="#working-with-blueprints"title="Link to this heading">¶</a></h2>
<p>If you have larger applications it’s recommended to divide them into
smaller groups where each group is implemented with the help of a
blueprint. For a gentle introduction into this topic refer to the
<aclass="reference internal"href="../blueprints.html"><spanclass="doc">Modular Applications with Blueprints</span></a> chapter of the documentation.</p>
