[docs] Add explanation section to torch.package docs (#59833)

Meghan Lele · facebook-github-bot · commit 0e222db08749 · 2021-06-10T19:52:48.000-07:00
Summary: Pull Request resolved: #59833 **Summary** This commit adds an explanation section to the `torch.package` documentation. This section clarifies and illuminates various aspects of the internals of `torch.package` that might be of interest to users. **Test Plan** Continuous integration. Test Plan: Imported from OSS Reviewed By: Lilyjjo Differential Revision: D29050626 Pulled By: SplitInfinity fbshipit-source-id: 78e0cda00f69506ef2dfc52d6df63694b502269e
diff --git a/docs/source/package.rst b/docs/source/package.rst
@@ -308,7 +308,7 @@ Now, the code will behave differently depending on whether it’s imported norma
     loaded_module.is_in_package()  # True
 
 
-*Warning*: in general, it’s bad practice to have code that behaves differently depending on whether it’s packaged or not. This can lead to
+**Warning**: in general, it’s bad practice to have code that behaves differently depending on whether it’s packaged or not. This can lead to
 hard-to-debug issues that are sensitive to how you imported your code. If your package is intended to be heavily used, consider restructuring
 your code so that it behaves the same way no matter how it was loaded.
 
@@ -451,6 +451,329 @@ Saving TorchScript objects that are attributes or submodules is supported as wel
     loaded_mixed = importer.load_pickle("res", "mixed_model.pkl"
 
 
+Explanation
+-----------
+``torch.package`` Format Overview
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+A ``torch.package`` file is a ZIP archive which conventionally uses the ``.pt`` extension. Inside the ZIP archive, there are two kinds of files:
+
+* Framework files, which are placed in the ``.data/``.
+* User files, which is everything else.
+
+As an example, this is what a fully packaged ResNet model from ``torchvision`` looks like:
+
+
+::
+
+    resnet
+    ├── .data  # All framework-specific data is stored here.
+    │   │      # It's named to avoid conflicts with user-serialized code.
+    │   ├── 94286146172688.storage  # tensor data
+    │   ├── 94286146172784.storage
+    │   ├── extern_modules  # text file with names of extern modules (e.g. 'torch')
+    │   ├── version         # version metadata
+    │   ├── ...
+    ├── model  # the pickled model
+    │   └── model.pkl
+    └── torchvision  # all code dependencies are captured as source files
+        └── models
+            ├── resnet.py
+            └── utils.py
+
+
+Framework files
+"""""""""""""""
+The ``.data/`` directory is owned by torch.package, and its contents are considered to be a private implementation detail.
+The ``torch.package`` format makes no guarantees about the contents of ``.data/``, but any changes made will be backward compatible
+(that is, newer version of PyTorch will always be able to load older ``torch.packages``).
+
+Currently, the ``.data/`` directory contains the following items:
+
+* ``version``: a version number for the serialized format, so that the ``torch.package`` import infrastructures knows how to load this package.
+* ``extern_modules``: a list of modules that are considered ``extern:class:`PackageImporter`. ``extern`` modules will be imported using the loading environment’s system importer.
+* ``*.storage``: serialized tensor data.
+
+
+::
+
+    .data
+    ├── 94286146172688.storage
+    ├── 94286146172784.storage
+    ├── extern_modules
+    ├── version
+    ├── ...
+
+
+User files
+""""""""""
+All other files in the archive were put there by a user. The layout is identical to a Python
+`regular package <https://docs.python.org/3/reference/import.html#regular-packages>`_. For a deeper dive in how Python packaging works,
+please consult `this essay <https://www.python.org/doc/essays/packages/>`_ (it’s slightly out of date, so double-check implementation details
+with the `Python reference documentation <https://docs.python.org/3/library/importlib.html>`_).
+
+
+::
+
+    <package root>
+    ├── model  # the pickled model
+    │   └── model.pkl
+    ├── another_package
+    │   ├── __init__.py
+    │   ├── foo.txt         # a resource file , see importlib.resources
+    │   └── ...
+    └── torchvision
+        └── models
+            ├── resnet.py   # torchvision.models.resnet
+            └── utils.py    # torchvision.models.utils
+
+
+How ``torch.package`` finds your code's dependencies
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Analyzing an object's dependencies
+""""""""""""""""""""""""""""""""""
+When you issue a ``save_pickle(obj, ...)`` call, :class:`PackageExporter` will pickle the object normally. Then, it uses the
+``pickletools`` standard library module to parse the pickle bytecode.
+
+In a pickle, an object is saved along with a ``GLOBAL`` opcode that describes where to find the implementation of the object’s type, like:
+
+
+::
+
+    GLOBAL 'torchvision.models.resnet Resnet`
+
+
+The dependency resolver will gather up all ``GLOBAL`` ops and mark them as dependencies of your pickled object.
+For more information about pickling and the pickle format, please consult `the Python docs <https://docs.python.org/3/library/pickle.html>`_.
+
+Analyzing a module's dependencies
+"""""""""""""""""""""""""""""""""
+When a Python module is identified as a dependency, ``torch.package`` walks the module’s python AST representation and looks for import statements with
+full support for the standard forms: ``from x import y``, ``import z``, ``from w import v as u``, etc. When one of these import statements are
+encountered, ``torch.package`` registers the imported modules as dependencies that are then themselves parsed in the same AST walking way.
+
+**Note**: AST parsing has limited support for the ``__import__(...)`` syntax and does not support ``importlib.import_module`` calls. In general, you should
+not expect dynamic imports to be detected by ``torch.package``.
+
+
+Dependency Management
+^^^^^^^^^^^^^^^^^^^^^
+``torch.package`` automatically finds the Python modules that your code and objects depend on. This process is called dependency resolution.
+For each module that the dependency resolver finds, you must specify an *action* to take.
+
+The allowed actions are:
+
+* ``intern``: put this module into the package.
+* ``extern``: declare this module as an external dependency of the package.
+* ``mock``: stub out this module.
+* ``deny``: depending on this module will raise an error during package export.
+
+Finally, there is one more important action that is not technically part of ``torch.package``:
+
+* Refactoring: remove or change the dependencies in your code.
+
+Note that actions are only defined on entire Python modules. There is no way to package “just” a function or class from module and leave the rest out.
+This is by design. Python does not offer clean boundaries between objects defined in a module. The only defined unit of dependency organization is a
+module, so that’s what ``torch.package`` uses.
+
+Actions are applied to modules using patterns. Patterns can either be module names (``"foo.bar"``) or globs (like ``"foo.**"``). You associate a pattern
+with an action using methods on :class:`PackageImporter`, e.g.
+
+
+::
+
+    my_exporter.intern("torchvision.**")
+    my_exporter.extern("numpy")
+
+
+If a module matches a pattern, the corresponding action is applied to it. For a given module, patterns will be checked in the order that they were defined,
+and the first action will be taken.
+
+
+``intern``
+""""""""""
+If a module is ``intern``-ed, it will be placed into the package.
+
+This action is your model code, or any related code you want to package. For example, if you are trying to package a ResNet from ``torchvision``,
+you will need to ``intern`` the module torchvision.models.resnet.
+
+On package import, when your packaged code tries to import an ``intern``-ed module, PackageImporter will look inside your package for that module.
+If it can’t find that module, an error will be raised. This ensures that each :class:`PackageImporter` is isolated from the loading environment—even
+if you have ``my_interned_module`` available in both your package and the loading environment, :class:`PackageImporter` will only use the version in your
+package.
+
+**Note**: Only Python source modules can be ``intern``-ed. Other kinds of modules, like C extension modules and bytecode modules, will raise an error if
+you attempt to ``intern`` them. These kinds of modules need to be ``mock``-ed or ``extern``-ed.
+
+
+``extern``
+""""""""""
+If a module is ``extern``-ed, it will not be packaged. Instead, it will be added to a list of external dependencies for this package. You can find this
+list on ``package_exporter.extern_modules``.
+
+On package import, when time packaged code tries to import an ``extern``-ed module, :class:`PackageImporter` will use the default Python importer to find
+that module, as if you did ``importlib.import_module("my_externed_module")``. If it can’t find that module, an error will be raised.
+
+In this way, you can depend on third-party libraries like ``numpy`` and ``scipy`` from within your package without having to package them too.
+
+**Warning**: If any external library changes in a backwards-incompatible way, your package may fail to load. If you need long-term reproducibility
+for your package, try to limit your use of ``extern``.
+
+
+``mock``
+""""""""
+If a module is ``mock``-ed, it will not be packaged. Instead a stub module will be packaged in its place. The stub module will allow you to retrieve
+objects from it (so that ``from my_mocked_module import foo`` will not error), but any use of that object will raise a ``NotImplementedError``.
+
+``mock`` should be used for code that you “know” will not be needed in the loaded package, but you still want to available for use in non-packaged contents.
+For example, initialization/configuration code, or code only used for debugging/training.
+
+**Warning**: In general, ``mock`` should be used as a last resort. It introduces behavioral differences between packaged code and non-packaged code,
+which may lead to later confusion. Prefer instead to refactor your code to remove unwanted dependencies.
+
+
+Refactoring
+"""""""""""
+The best way to manage dependencies is to not have dependencies at all! Often, code can be refactored to remove unnecessary dependencies. Here are some
+guidelines for writing code with clean dependencies (which are also generally good practices!):
+
+**Include only what you use**. Do not leave unused imports in our code. The dependency resolver is not smart enough to tell that they are indeed unused,
+and will try to process them.
+
+**Qualify your imports**. For example, instead of writing import foo and later using ``foo.bar.baz``, prefer to write ``from foo.bar import baz``. This more
+precisely specifies your real dependency (``foo.bar``) and lets the dependency resolver know you don’t need all of ``foo``.
+
+**Split up large files with unrelated functionality into smaller ones**. If your ``utils`` module contains a hodge-podge of unrelated functionality, any module
+that depends on ``utils`` will need to pull in lots of unrelated dependencies, even if you only needed a small part of it. Prefer instead to define
+single-purpose modules that can be packaged independently of one another.
+
+
+Patterns
+""""""""
+Patterns allow you to specify groups of modules with a convenient syntax. The syntax and behavior of patterns follows the Bazel/Buck
+`glob() <https://docs.bazel.build/versions/master/be/functions.html#glob>`_.
+
+A module that we are trying to match against a pattern is called a candidate. A candidate is composed of a list of segments separated by a
+separator string, e.g. ``foo.bar.baz``.
+
+A pattern contains one or more segments. Segments can be:
+
+* A literal string (e.g. ``foo``), which matches exactly.
+* A string containing a wildcard (e.g. ``torch``, or ``foo*baz*``). The wildcard matches any string, including the empty string.
+* A double wildcard (``**``). This matches against zero or more complete segments.
+
+Examples:
+
+* ``torch.**``: matches ``torch`` and all its submodules, e.g. ``torch.nn`` and ``torch.nn.functional``.
+* ``torch.*``: matches ``torch.nn`` or ``torch.functional``, but not ``torch.nn.functional`` or ``torch``
+* ``torch*.**``: matches ``torch``, ``torchvision``, and all of their submodules
+
+When specifying actions, you can pass multiple patterns, e.g.
+
+
+::
+
+    exporter.intern(["torchvision.models.**", "torchvision.utils.**"])
+
+
+A module will match against this action if it matches any of the patterns.
+
+You can also specify patterns to exlcude, e.g.
+
+
+::
+
+    exporter.mock("**", exclude=["torchvision.**"])
+
+
+A module will not match against this action if it matches any of the exclude patterns. In this example, we are mocking all modules except
+``torchvision`` and its submodules.
+
+When a module could potentially match against multiple actions, the first action defined will be taken.
+
+
+``torch.package`` sharp edges
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Avoid global state in your modules
+""""""""""""""""""""""""""""""""""
+Python makes it really easy to bind objects and run code at module-level scope. This is generally fine—after all, functions and classes are bound to
+names this way. However, things become more complicated when you define an object at module scope with the intention of mutating it, introducing mutable
+global state.
+
+Mutable global state is quite useful—it can reduce boilerplate, allow for open registration into tables, etc. But unless employed very carefully, it can
+cause complications when used with ``torch.package``.
+
+Every :class:`PackageImporter` creates an independent environment for its contents. This is nice because it means we load multiple packages and ensure
+they are isolated from each other, but when modules are written in a way that assumes shared mutable global state, this behavior can create hard-to-debug
+errors.
+
+Types are not shared between packages and the loading environment
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+Any class that you import from a :class:`PackageImporter` will be a version of the class specific to that importer. For example:
+
+
+::
+
+    from foo import MyClass
+
+    my_class_instance = MyClass()
+
+    with PackageExporter(f) as exporter:
+        exporter.save_module("foo")
+
+    importer = PackageImporter(f)
+    imported_MyClass = importer.import_module("foo").MyClass
+
+    assert isinstance(my_class_instance, MyClass)  # works
+    assert isinstance(my_class_instance, imported_MyClass)  # ERROR!
+
+
+In this example, ``MyClass`` and ``import_MyClass`` are *not the same type*. In this specific example, ``MyClass`` and ``import_MyClass`` have exactly the
+same implementation, so you might thing it’s okay to consider them the same class. But consider the situation where ``import_MyClass`` is coming from an
+older package with an entirely different implementation of ``MyClass`` — in that case, it’s unsafe to consider them the same class.
+
+Under the hood, each importer has a prefix that allows it to uniquely identify classes:
+
+
+::
+
+    print(MyClass.__name__)  # prints "foo.MyClass"
+    print(imported_MyClass.__name__)  # prints <torch_package_0>.foo.MyClass
+
+
+That means you should not expect ``isinstance`` checks to work when one of the arguments if from a package and the other is not. If you need this
+functionality, consider the following options:
+
+* Doing duck typing (just using the class instead of explicitly checking that it is of a given type).
+* Make the typing relationship an explicit part of the class contract. For example, you can add an attribute tag ``self.handler = "handle_me_this_way"`` and have client code check for the value of ``handler`` instead of checking the type directly.
+
+
+How ``torch.package`` keeps packages isolated from each other
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Each :class:`PackageImporter` instance creates an independent, isolated environment for its modules and objects. Modules in a package can only import
+other packaged modules, or modules marked ``extern``. If you use multiple :class:`PackageImporter` instances to load a single package, you will get
+multiple independent environments that do not interact.
+
+This is achieved by extending Python’s import infrastructure with a custom importer. :class:`PackageImporter` provides the same core API as the
+``importlib`` importer; namely, it implements the ``import_module`` and ``__import__`` methods.
+
+When you invoke :meth:`PackageImporter.import_module`, :class:`PackageImporter` will construct and return a new module, much as the system importer does.
+However, :class:`PackageImporter` patches the returned module to use ``self`` (i.e. that :class:`PackageImporter` instance) to fulfill future import
+requests by looking in the package rather than searching the user’s Python environment.
+
+Mangling
+""""""""
+To avoid confusion (“is this ``foo.bar`` object the one from my package, or the one from my Python environment?”), :class:`PackageImporter` mangles the
+``__name__`` and ``__file__`` of all imported modules, by adding a *mangle prefix* to them.
+
+For ``__name__``, a name like ``torchvision.models.resnet18`` becomes ``<torch_package_0>.torchvision.models.resnet18``.
+
+For ``__file__``, a name like ``torchvision/models/resnet18.py`` becomes ``<torch_package_0>.torchvision/modules/resnet18.py``.
+
+Name mangling helps avoid inadvertent punning of module names between different packages, and helps you debug by making stack traces and print
+statements more clearly show whether they are referring to packaged code or not. For developer-facing details about mangling, consult
+``mangling.md`` in ``torch/package/``.
+
+
 API Reference
 -------------
 .. autoclass:: torch.package.PackagingError
