|
| 1 | +.. _dynamic_versioning: |
| 2 | + |
| 3 | +Dynamic Versioning |
| 4 | +================== |
| 5 | + |
| 6 | +Overview |
| 7 | +-------- |
| 8 | + |
| 9 | +The Dynamic Versioning system in Fine-Tuning Scheduler (FTS) enables constrained self-modification of |
| 10 | +the ``finetuning-scheduler`` package itself. The initial application of this feature is to dynamically orchestrate |
| 11 | +management of Lightning package imports, making it easy to switch between the unified ``lightning`` package and the |
| 12 | +standalone ``pytorch-lightning`` package. |
| 13 | + |
| 14 | +This feature is particularly useful for: |
| 15 | + |
| 16 | +- Adapting existing code to work with different Lightning package import styles |
| 17 | +- Testing compatibility with both unified and standalone Lightning |
| 18 | +- Migrating projects from one import style to another |
| 19 | + |
| 20 | +Toggling Lightning Import Styles |
| 21 | +--------------------------------- |
| 22 | + |
| 23 | +After installing FTS, you can switch between unified and standalone imports using the ``toggle-lightning-mode`` |
| 24 | +command-line tool: |
| 25 | + |
| 26 | +.. code-block:: bash |
| 27 | +
|
| 28 | + # Switch to standalone imports (pytorch_lightning) |
| 29 | + toggle-lightning-mode --mode standalone |
| 30 | +
|
| 31 | + # Switch back to unified imports (lightning.pytorch) |
| 32 | + toggle-lightning-mode --mode unified |
| 33 | +
|
| 34 | +The tool performs the following actions: |
| 35 | + |
| 36 | +1. Checks if the requested package is installed |
| 37 | +2. Scans all Python files in the FTS package |
| 38 | +3. Updates import statements to match the requested style |
| 39 | +4. Preserves functionality while changing only the import paths |
| 40 | + |
| 41 | +.. note:: |
| 42 | + You must have the target package installed before toggling. For example, to toggle to unified mode, |
| 43 | + the ``lightning`` package must be installed, and to toggle to standalone mode, the ``pytorch-lightning`` |
| 44 | + package must be installed. |
| 45 | + |
| 46 | +Implementation Details |
| 47 | +---------------------- |
| 48 | + |
| 49 | +The dynamic versioning system: |
| 50 | + |
| 51 | +- Uses pattern matching to identify Lightning imports |
| 52 | +- Excludes certain files from modification to prevent self-modification |
| 53 | +- Supports both source and installed package directories |
| 54 | +- Automatically handles all import variations (direct imports, from imports, etc.) |
| 55 | + |
| 56 | +The conversion operations are individually idempotent and mutually reversible, making it safe to run the toggle |
| 57 | +command multiple times. |
| 58 | + |
| 59 | +Using Lightning CI Commit Pinning |
| 60 | +---------------------------------- |
| 61 | + |
| 62 | +For development and testing, FTS supports pinning to a specific Lightning commit via the ``USE_CI_COMMIT_PIN`` |
| 63 | +environment variable. This approach is similar to PyTorch's approach with Triton: |
| 64 | + |
| 65 | +.. code-block:: bash |
| 66 | +
|
| 67 | + # Enable Lightning CI commit pinning during installation |
| 68 | + export USE_CI_COMMIT_PIN="1" |
| 69 | +
|
| 70 | + # Install FTS with pinned Lightning commit |
| 71 | + pip install finetuning-scheduler |
| 72 | +
|
| 73 | + # Or for development installation |
| 74 | + git clone https://github.com/speediedan/finetuning-scheduler.git |
| 75 | + cd finetuning-scheduler |
| 76 | + python -m pip install -e ".[all]" |
| 77 | +
|
| 78 | +The specific Lightning commit is defined in ``requirements/lightning_pin.txt`` and is used by the CI system to |
| 79 | +ensure consistent testing. |
0 commit comments