One of the great difficulties in modern software development is that of dependency management. Generally, a dependency of a software project consists of a library or component that is required for the project to function correctly. In the case of a Flask application (and more generally, that of a Python application), most dependencies are comprised of specially organized and annotated source files. Once created, these packages of source files may then be included in other projects and so forth. For some, this chain of dependencies can become an unmanageable mess, where the slightest alteration to any of the libraries in the chain can cause a cascade of incompatibilities that would bring further development to a screeching halt. In the Python world, as you may know already, the fundamental unit of a reusable set of source files is that of a Python module (a file that contains definitions and statements). Once you've created a module on your local filesystem and ensured that it is in your system's PYTHONPATH, including it in a newly created project is as simple as specifying the import, which is as follows:

import the_custom_module

Where the_custom_module.py is a file that exists somewhere in $PYTHONPATH of the system executing the program.

This is not where the story ends, of course. While modules littering your local filesystem might be convenient at first, what happens when you want to share some of the code that you've written for others? Usually, this would entail emailing/Dropboxing the files in question, however, this is obviously a very cumbersome and error-prone solution. Thankfully, this is a problem that has been considered and some progress has been made in alleviating the common issues. The most significant of these advances is the subject of this chapter, and how the following techniques for creating reusable, isolated packages of code can be leveraged to ease the development of a Flask application:

The solution presented by the various Python packaging paradigms/libraries is far from perfect; one sure way to start an argument with a passionate Python developer is to proclaim that the packaging problem has been solved! We still have a long way to go for that but headway is being made in incremental steps with improvements to setuptools and various other libraries used in building, maintaining, and distributing a reusable Python code.

In this chapter, when we refer to a package, what we will actually be talking about would be succinctly described as a distribution—a bundle of software to be installed from a remote source—and not a collection of modules in a folder structure that utilizes the__init__.py convention in order to delineate the folders containing the modules that we want to be importable.