`LightningArgumentParser` fails to instantiate classes with `add_lightning_class_args`

[adosar]

Bug description

LightningArgumentParser doesn't instantiate classes when a lightning class (e.g. Trainer) is added via add_lightning_class_args. If this is not really a bug, what is the benefit of using add_lightning_class_args over just add_class_arguments for lightning classes?

What version are you seeing the problem on?

v2.5

How to reproduce the bug

from lightning.pytorch.cli import LightningArgumentParser
import lightning as L

parser = LightningArgumentParser()
parser.add_lightning_class_args(L.Trainer, 'trainer')
cfg = parser.parse_args()
cfg = parser.instantiate_classes(cfg)
print('With add_lightning_class_args', type(cfg.trainer))

parser = LightningArgumentParser()
parser.add_class_arguments(L.Trainer, 'trainer')
cfg = parser.parse_args()
cfg = parser.instantiate_classes(cfg)
print('With add_class_arguments', type(cfg.trainer))

Error messages and logs

With add_lightning_class_args <class 'jsonargparse._namespace.Namespace'>                                                                                                                     
GPU available: False, used: False                                                                                                                                                             
TPU available: False, using: 0 TPU cores                                                                                                                                                      
HPU available: False, using: 0 HPUs                                                                                                                                                           
/home/asar/venvir/aidsorb/lib64/python3.12/site-packages/lightning/pytorch/trainer/connectors/logger_connector/logger_connector.py:76: Starting from v1.9.0, `tensorboardX` has been removed a
s a dependency of the `lightning.pytorch` package, due to potential conflicts with other packages in the ML ecosystem. For this reason, `logger=True` will use `CSVLogger` as the default logg
er, unless the `tensorboard` or `tensorboardX` packages are found. Please `pip install lightning[extra]` or one of them to enable TensorBoard support by default                              
With add_class_arguments <class 'lightning.pytorch.trainer.trainer.Trainer'>    

Environment

Current environment

Collecting environment information...
PyTorch version: 2.5.1+cu124
Is debug build: False
CUDA used to build PyTorch: 12.4
ROCM used to build PyTorch: N/A

OS: Fedora Linux 39 (Workstation Edition) (x86_64)
GCC version: (GCC) 13.3.1 20240913 (Red Hat 13.3.1-3)
Clang version: Could not collect
CMake version: Could not collect
Libc version: glibc-2.38

Python version: 3.12.7 (main, Oct  1 2024, 00:00:00) [GCC 13.3.1 20240913 (Red Hat 13.3.1-3)] (64-bit runtime)
Python platform: Linux-6.11.9-100.fc39.x86_64-x86_64-with-glibc2.38
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Architecture:                         x86_64
CPU op-mode(s):                       32-bit, 64-bit
Address sizes:                        39 bits physical, 48 bits virtual
Byte Order:                           Little Endian
CPU(s):                               8
On-line CPU(s) list:                  0-7
Vendor ID:                            GenuineIntel
Model name:                           Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz
CPU family:                           6
Model:                                142
Thread(s) per core:                   2
Core(s) per socket:                   4
Socket(s):                            1
Stepping:                             10
CPU(s) scaling MHz:                   95%
CPU max MHz:                          3400.0000
CPU min MHz:                          400.0000
BogoMIPS:                             3600.00
Flags:                                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp vnmi md_clear flush_l1d arch_capabilities
Virtualization:                       VT-x
L1d cache:                            128 KiB (4 instances)
L1i cache:                            128 KiB (4 instances)
L2 cache:                             1 MiB (4 instances)
L3 cache:                             6 MiB (1 instance)
NUMA node(s):                         1
NUMA node0 CPU(s):                    0-7
Vulnerability Gather data sampling:   Mitigation; Microcode
Vulnerability Itlb multihit:          KVM: Mitigation: VMX disabled
Vulnerability L1tf:                   Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable
Vulnerability Mds:                    Mitigation; Clear CPU buffers; SMT vulnerable
Vulnerability Meltdown:               Mitigation; PTI
Vulnerability Mmio stale data:        Mitigation; Clear CPU buffers; SMT vulnerable
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed:               Mitigation; IBRS
Vulnerability Spec rstack overflow:   Not affected
Vulnerability Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:             Mitigation; IBRS; IBPB conditional; STIBP conditional; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
Vulnerability Srbds:                  Mitigation; Microcode
Vulnerability Tsx async abort:        Not affected

Versions of relevant libraries:
[pip3] numpy==1.26.4
[pip3] nvidia-cublas-cu12==12.4.5.8
[pip3] nvidia-cuda-cupti-cu12==12.4.127
[pip3] nvidia-cuda-nvrtc-cu12==12.4.127
[pip3] nvidia-cuda-runtime-cu12==12.4.127
[pip3] nvidia-cudnn-cu12==9.1.0.70
[pip3] nvidia-cufft-cu12==11.2.1.3
[pip3] nvidia-curand-cu12==10.3.5.147
[pip3] nvidia-cusolver-cu12==11.6.1.9
[pip3] nvidia-cusparse-cu12==12.3.1.170
[pip3] nvidia-nccl-cu12==2.21.5
[pip3] nvidia-nvjitlink-cu12==12.4.127
[pip3] nvidia-nvtx-cu12==12.4.127
[pip3] pytorch-lightning==2.2.0.post0
[pip3] torch==2.5.1
[pip3] torchmetrics==1.3.1
[pip3] torchvision==0.20.1
[pip3] torchviz==0.0.2
[pip3] triton==3.1.0
[conda] Could not collect

More info

No response

cc @mauvilsa

[mauvilsa]

The LightningArgumentParser class was implemented because of LightningCLI, so add_lightning_class_args does what LightningCLI needs. In the case of Trainer, what it does is disable instantiation, see cli.py#L154. That is because LightningCLI needs to instantiate the trainer itself. This is actually a limitation of LightningCLI since for example it is not possible to create links involving the trainer. It would be nice to remove this limitation some day.

In my opinion there is little use of LightningArgumentParser if it is not related to LightningCLI. If you are building your own parsers, then why not use the normal jsonargparse.ArgumentParser?

[adosar]

Hi @mauvilsa,

From the docs "Extension of jsonargparse’s ArgumentParser for pytorch-lightning" I thought that it should be preferred when working with Lightning over jsonargparse.ArgumentParser.