@@ -1448,6 +1448,69 @@ find and load modules.
1448
1448
Boolean indicating whether or not the module's "origin"
1449
1449
attribute refers to a loadable location.
1450
1450
1451
+ .. class :: AppleFrameworkLoader(name, path)
1452
+
1453
+ A specialization of :class: `importlib.machinery.ExtensionFileLoader ` that
1454
+ is able to load extension modules in Framework format.
1455
+
1456
+ For compatibility with the iOS App Store, *all * binary modules in an iOS app
1457
+ must be dynamic libraries, contained in a framework with appropriate
1458
+ metadata, stored in the ``Frameworks `` folder of the packaged app. There can
1459
+ be only a single binary per framework, and there can be no executable binary
1460
+ material outside the Frameworks folder.
1461
+
1462
+ To accomodate this requirement, when running on iOS, extension module
1463
+ binaries are *not * packaged as ``.so `` files on ``sys.path ``, but as
1464
+ individual standalone frameworks. To discover those frameworks, this loader
1465
+ is be registered against the ``.fwork `` file extension, with a ``.fwork ``
1466
+ file acting as a placeholder in the original location of the binary on
1467
+ ``sys.path ``. The ``.fwork `` file contains the path of the actual binary in
1468
+ the ``Frameworks `` folder, relative to the app bundle. To allow for
1469
+ resolving a framework-packaged binary back to the original location, the
1470
+ framework is expected to contain a ``.origin `` file that contains the
1471
+ location of the ``.fwork `` file, relative to the app bundle.
1472
+
1473
+ For example, consider the case of an import ``from foo.bar import _whiz ``,
1474
+ where ``_whiz `` is implemented with the binary module
1475
+ ``sources/foo/bar/_whiz.abi3.so ``, with ``sources `` being the location
1476
+ registered on ``sys.path ``, relative to the application bundle. This module
1477
+ *must * be distributed as
1478
+ ``Frameworks/foo.bar._whiz.framework/foo.bar._whiz `` (creating the framework
1479
+ name from the full import path of the module), with an ``Info.plist `` file
1480
+ in the ``.framework `` directory identifying the binary as a framework. The
1481
+ ``foo.bar._whiz `` module would be represented in the original location with
1482
+ a ``sources/foo/bar/_whiz.abi3.fwork `` marker file, containing the path
1483
+ ``Frameworks/foo.bar._whiz/foo.bar._whiz ``. The framework would also contain
1484
+ ``Frameworks/foo.bar._whiz.framework/foo.bar._whiz.origin ``, containing the
1485
+ path to the ``.fwork `` file.
1486
+
1487
+ When a module is loaded with this loader, the ``__file__ `` for the module
1488
+ will report as the location of the ``.fwork `` file. This allows code to use
1489
+ the ``__file__ `` of a module as an anchor for file system traveral.
1490
+ However, the spec origin will reference the location of the *actual * binary
1491
+ in the ``.framework `` folder.
1492
+
1493
+ The Xcode project building the app is responsible for converting any ``.so ``
1494
+ files from wherever they exist in the ``PYTHONPATH `` into frameworks in the
1495
+ ``Frameworks `` folder (including stripping extensions from the module file,
1496
+ the addition of framework metadata, and signing the resulting framework),
1497
+ and creating the ``.fwork `` and ``.origin `` files. This will usually be done
1498
+ with a build step in the Xcode project; see the iOS documentation for
1499
+ details on how to construct this build step.
1500
+
1501
+ .. versionadded :: 3.13
1502
+
1503
+ .. availability :: iOS.
1504
+
1505
+ .. attribute :: name
1506
+
1507
+ Name of the module the loader supports.
1508
+
1509
+ .. attribute :: path
1510
+
1511
+ Path to the ``.fwork `` file for the extension module.
1512
+
1513
+
1451
1514
:mod: `importlib.util ` -- Utility code for importers
1452
1515
---------------------------------------------------
1453
1516
0 commit comments