🚀 Feature

Initial discussion here.

Motivation

Lightning's messaging in errors is always oriented towards providing a resolution for the user. The previous way was to say
"pip install package-name" when a package cloud not be imported. This was recently removed in #14715 with the motivation to add it back to RequirementCache.

Pitch

As proposed by @carmocca

Alternatives

Additional context

🐛 Bug

ImportError: cannot import name '_PATH' from 'pytorch_lightning.utilities.types' (C:\Users\tmcquaig\anaconda3\envs\Dreambooth-SD\lib\site-packages\pytorch_lightning\utilities\types.py)

To Reproduce

Steps to reproduce the behavior:

1. Installed Anaconda and https://github.com/JoePenna/Dreambooth-Stable-Diffusion
2. In the DreamBooth-SD environment created for in Ananconda, run "python main.py"

(Dreambooth-SD) E:\Dreambooth-Stable-Diffusion>python main.py
Traceback (most recent call last):
  File "E:\Dreambooth-Stable-Diffusion\main.py", line 2, in <module>
    from ldm.modules.pruningckptio import PruningCheckpointIO
  File "E:\Dreambooth-Stable-Diffusion\ldm\modules\pruningckptio.py", line 4, in <module>
    from pytorch_lightning.utilities.types import _PATH
ImportError: cannot import name '_PATH' from 'pytorch_lightning.utilities.types' (C:\Users\tmcquaig\anaconda3\envs\Dreambooth-SD\lib\site-packages\pytorch_lightning\utilities\types.py)

(Dreambooth-SD) E:\Dreambooth-Stable-Diffusion>pip show lightning-utilities
Name: lightning-utilities
Version: 0.4.2
Summary: PyTorch Lightning Sample project.
Home-page: https://github.com/Lightning-AI/utilities
Author: Lightning AI et al.
Author-email: [email protected]
License: Apache-2.0
Location: c:\users\tmcquaig\anaconda3\envs\dreambooth-sd\lib\site-packages
Requires:
Required-by: pytorch-lightning

(Dreambooth-SD) E:\Dreambooth-Stable-Diffusion>

Code sample

main.py", line 2, in <module>

`from` ldm.modules.pruningckptio import `PruningCheckpointIO`

pruningckptio.py", line 4, in <module>

`from` pytorch_lightning.utilities.types import `_PATH`

Expected behavior

main.py should successfully run and Dreambooth Stable Diffusion should run :)

Environment

(Dreambooth-SD) E:\Dreambooth-Stable-Diffusion>conda info

     active environment : Dreambooth-SD
    active env location : C:\Users\tmcquaig\anaconda3\envs\Dreambooth-SD
            shell level : 2
       user config file : C:\Users\tmcquaig\.condarc
 populated config files : C:\Users\tmcquaig\.condarc
          conda version : 22.11.1
    conda-build version : 3.22.0
         python version : 3.9.13.final.0
       virtual packages : __archspec=1=x86_64
                          __cuda=12.0=0
                          __win=0=0
       base environment : C:\Users\tmcquaig\anaconda3  (writable)
      conda av data dir : C:\Users\tmcquaig\anaconda3\etc\conda
  conda av metadata url : None
           channel URLs : https://repo.anaconda.com/pkgs/main/win-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/win-64
                          https://repo.anaconda.com/pkgs/r/noarch
                          https://repo.anaconda.com/pkgs/msys2/win-64
                          https://repo.anaconda.com/pkgs/msys2/noarch
          package cache : C:\Users\tmcquaig\anaconda3\pkgs
                          C:\Users\tmcquaig\.conda\pkgs
                          C:\Users\tmcquaig\AppData\Local\conda\conda\pkgs
       envs directories : C:\Users\tmcquaig\anaconda3\envs
                          C:\Users\tmcquaig\.conda\envs
                          C:\Users\tmcquaig\AppData\Local\conda\conda\envs
               platform : win-64
             user-agent : conda/22.11.1 requests/2.28.1 CPython/3.9.13 Windows/10 Windows/10.0.22621
          administrator : False
             netrc file : None
           offline mode : False


(Dreambooth-SD) E:\Dreambooth-Stable-Diffusion>

(Dreambooth-SD) E:\Dreambooth-Stable-Diffusion>pip list
Package             Version
------------------- -----------
aiohttp             3.8.3
aiosignal           1.3.1
async-timeout       4.0.2
attrs               22.1.0
certifi             2022.9.24
charset-normalizer  2.1.1
colorama            0.4.6
frozenlist          1.3.3
fsspec              2022.11.0
idna                3.4
lightning-utilities 0.4.2
multidict           6.0.3
numpy               1.23.5
packaging           22.0
pip                 22.3.1
protobuf            3.20.1
pytorch-lightning   1.8.4.post0
PyYAML              6.0
requests            2.28.1
setuptools          65.5.0
tensorboardX        2.5.1
torch               1.13.0
torchmetrics        0.11.0
tqdm                4.64.1
typing_extensions   4.4.0
urllib3             1.26.13
wheel               0.37.1
wincertstore        0.2
yarl                1.8.2

(Dreambooth-SD) E:\Dreambooth-Stable-Diffusion>

Additional context

📚 Documentation

Document that the rank_zero_only function only works as intended once the actual rank is set, i.e., rank_zero_only.rank = x. This needs to be handled by the application that uses this function.

Bug

src/lightning_utilities/core/imports.py imports pkg_resources, which is deprecated (since at least 2020) in favor of importlib.resources, importlib.metadata, and their backports (importlib_resources, importlib_metadata). See here.

To Reproduce

PYTHONWARNINGS=default::DeprecationWarning python -c 'import torchmetrics'

(or import lightning_utilities)

🚀 Feature

See title. Feel free to close if you disagree

🐛 Bug

Seems we have a bug in the utils package, as this code for installing only PL from source return both true...

To Reproduce

Lightning-AI/pytorch-lightning#16595 (comment)

Code sample

from lightning_utilities.core.imports import package_available
print(module_available("lightning"))
print(module_available("pytorch_lightning"))

Expected behavior

Environment

• lightning-utilities==0.6.0.post0

Additional context

🚀 Feature

CHANGELOG.md is currently empty. We use GitHub's release notes auto-generation

Motivation

Be consistent

Pitch

Update CHANGELOG.md and the existing releases.

Alternatives

Keep using the auto-generation button

🐛 Bug

lightning_utilities.core.apply_func.apply_to_collection breaks homogeneous named tuples, forcing conversion to simple tuples. This results in a forced conversion of NamedTuple-based batches from the dataloader to tuples in Lightning.

To Reproduce

Reproducing the bug in Lightning requires creating model + dataloader with NamedTuple output.

Reproducing the problem in Lightning-Utilities is easier, see the snippet below:

from lightning_utilities.core.apply_func import apply_to_collection
import torch
from typing import NamedTuple

class NamedTupleBatch(NamedTuple):
    x: torch.Tensor
    y: torch.Tensor

def test_apply_to_collection():
    batch = NamedTupleBatch(x=torch.rand(10, 10), y=torch.rand(10, 10))
    assert isinstance(batch, NamedTupleBatch)  # before
    batch_out = apply_to_collection(batch, torch.Tensor, lambda x: x.to("cpu"))
    assert isinstance(batch_out, NamedTupleBatch)  # after - broken

Expected behavior

apply_to_collection should return the NamedTuple (if input is of NamedTuple type) instead of force-casting it to simple tuple.

Additional context

I think that the problem was introduced in #160
Lightning Utilities version 0.9.0 is fine, but 0.10.0 breaks named tuples.

I think that the behavior is incorrect in

if isinstance(data, tuple) and all(isinstance(x, dtype) for x in data):  # 1d homogeneous tuple
    return tuple(function(x, *args, **kwargs) for x in data)

Potential fix:

if isinstance(data, tuple) and all(isinstance(x, dtype) for x in data):  # 1d homogeneous tuple
    if is_namedtuple(data):
        return type(data)(*[function(x, *args, **kwargs) for x in data])
    else:
        return tuple(function(x, *args, **kwargs) for x in data)

🚀 Feature

Motivation

As we moved in several projects to have link validation (detecting dead links) as optional, so if failed job still passes, it is almost as if it is not there because people will ignore it, so have an action that would parse and comment on PR with dead/broken links

Alternatives

make the link check again as required, and part of our build

Additional context

see: Lightning-AI/torchmetrics#1626 (comment)

🚀 Feature

See title.

Motivation

dev sounds very ambiguous to me.

Alternatives

• Keep as is.
• Rename it to a different name.

Additional context

Since the cli subpackage will be used only in our CI, this issue shouldn't be highly prioritised.

Bug description

Lightning appears to depend on the setuptools package at runtime via an import of the pkg_resources module. However, setuptools is not listed as a dependency, causing import failures in some environments.

In particular, when using the PDM package manager, the virtualenv it uses behind the scenes does not by default include a setuptools distribution (as it is typically only needed in the build environment). This means that installing lightning via pdm leads to a failure at import time. However, the issue can be reproduced in a standard virtualenv by simply uninstalling setuptools.

This bug seems to have been introduced in 2.1.x, and I have confirmed it in python 3.9.18 and 3.11.6.

What version are you seeing the problem on?

v2.1

How to reproduce the bug

python -m venv venv
source venv/bin/activate
pip uninstall -y setuptools
pip install lightning

python -c "import lightning" || python -c "import lightning.pytorch"

Error messages and logs

  File "<string>", line 1, in <module>
  File ".../venv/lib/python3.11/site-packages/lightning/__init__.py", line 18, in <module>
    from lightning.fabric.fabric import Fabric  # noqa: E402
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File ".../venv/lib/python3.11/site-packages/lightning/fabric/__init__.py", line 5, in <module>
    from lightning_utilities.core.imports import package_available
  File ".../venv/lib/python3.11/site-packages/lightning_utilities/__init__.py", line 6, in <module>
    from lightning_utilities.core.apply_func import apply_to_collection
  File ".../venv/lib/python3.11/site-packages/lightning_utilities/core/__init__.py", line 4, in <module>
    from lightning_utilities.core.imports import compare_version, module_available
  File ".../venv/lib/python3.11/site-packages/lightning_utilities/core/imports.py", line 13, in <module>
    import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'

Environment

- PyTorch Lightning Version: 2.1.x
- Python: version 3.9, 3.11 (tested)
- MacOS: 13.5.1 (m1 processor)
- How you installed Lightning: pip, pdm

More info

No response

🚀 Feature

https://github.com/Lightning-AI/lightning/blob/ebc650bd95a4d09a8d77dc7e0379a6b9a909bb69/src/pytorch_lightning/utilities/enums.py#L23-L41

And rename it to StrEnum

It is used in PL and Lite

🚀 Feature

Motivation

aggregate configuration to only one file

Alternatives

see Lightning-AI/torchmetrics#1449

Additional context

🐛 Bug

The test module in lightning_utilities is not part of the package.

To Reproduce

Steps to reproduce the behavior:

from lightning_utilities.test.warning import no_warning_call

Code sample

from lightning_utilities.test.warning import no_warning_call

Expected behavior

Environment

Latest version 0.4.1

• PyTorch Version (e.g., 1.0):
• OS (e.g., Linux):
• How you installed PyTorch (conda, pip, source):
• Build command you used (if compiling from source):
• Python version:
• CUDA/cuDNN version:
• GPU models and configuration:
• Any other relevant information:

Additional context

I got the import from #55

🐛 Bug

In the latest version of the utilities library, automatic device transfer converts namedtuples into regular tuples, causing loss of attribute access provided by the namedtuple.

To Reproduce

from collections import namedtuple
import torch
from pytorch_lightning import LightningModule, Trainer

Batch = namedtuple("Batch", ["features", "targets"])

class SimpleModule(LightningModule):
    def __init__(self):
        super().__init__()
        self.linear = torch.nn.Linear(5, 1)
        
    def forward(self, batch):
        print(type(batch))
        print(batch.features)
        return self.linear(batch.features)

    def training_step(self, batch, batch_idx):
        return self(batch)

    def train_dataloader(self):
        features = torch.randn(10, 5)
        targets = torch.randint(0, 1, (10,))
        dataset = [Batch(features[i], targets[i]) for i in range(10)]
        return torch.utils.data.DataLoader(dataset, batch_size=1)
    
    def configure_optimizers(self):
        return torch.optim.Adam(self.parameters(), lr=1e-3)

model = SimpleModule()
trainer = Trainer(fast_dev_run=True)
trainer.fit(model)

This script fails with attribute error AttributeError: 'tuple' object has no attribute 'features', when the library version is 0.10.0 and runs without errors on 0.9.0. The Pytorch lightning version was unchanged, 2.1.2 for both.

Additional context

🚀 Feature

Motivation

RequirementCache exists, but it is very general. It works for both modules as well as packages. It has a very strict check for requirements of a package. This check can fail even if the package is actually importable successfully, see example: Lightning-AI/pytorch-lightning#16464

In these cases, the module_available check is better suited for what we want to check. But it can only be called as a function, not as a cache like the RequirementCache.

Pitch

Add ModuleAvailableCache, with a cache implementation like RequirementCache, but we will use the module_available function as as the check function.

Alternatives

User has to resolve any package conflicts in their environment, even if they are harmless.

Additional context

See Lightning-AI/pytorch-lightning#16464

🐛 Bug

After making release packages are not uploaded to Release artifacts

To Reproduce

https://github.com/Lightning-AI/utilities/actions/runs/3362708729/jobs/5574801044

Warning: Cannot upload assets for release which is being undefined

Additional context

🚀 Feature

Add a function to lightning_utilities/core/imports.py that returns the minimum version of a dependency of a package.

Motivation

The minimum version of a dependency could be needed in more than one place in the code. When a change is needed, this needs to be done in multiple places. The issue is that it can be forgotten to update one location. An example is requirements/pytorch/extra.txt#L8 and src/pytorch_lightning/cli.py#L32.

Maybe this could be useful in other cases.

Pitch

Be able to change

_JSONARGPARSE_SIGNATURES_AVAILABLE = RequirementCache("jsonargparse[signatures]>=4.12.0")

to

jsonargparse_min_version = get_minimum_dependency_version("pytorch-lightning", "jsonargparse")
_JSONARGPARSE_SIGNATURES_AVAILABLE = RequirementCache(f"jsonargparse[signatures]>={jsonargparse_min_version}")

A possible implementation of this function could be:

def get_minimum_dependency_version(package_name: str, dependency_name: str) -> str:
    """Returns the minimum version of a dependency of a package.

    >>> get_minimum_dependency_version("pytorch-lightning", "jsonargparse") 
    '4.12.0'
    """
    for dependency in metadata.requires(package_name):
        if re.match(f"^{dependency_name}(|[^\w].*)$", dependency):
            return re.sub(r".*>=([\d.]+).*", r"\1", dependency)
    raise ValueError(f"dependency {dependency_name!r} not found in package {package_name!r}")

Alternatives

Keep updating multiple places in the code. When there is a mistake, fix it later.

Additional context

None

🚀 Feature

Collect common classes, functions, e.g.

• RunIf: https://github.com/Lightning-AI/lightning/blob/95374440ce9b4f499f83b0e6b8cee0bc715aa18b/tests/tests_pytorch/helpers/runif.py#L55
• no_warning_call: https://github.com/Lightning-AI/lightning/blob/95374440ce9b4f499f83b0e6b8cee0bc715aa18b/tests/tests_pytorch/helpers/utils.py#L92
• ...

Motivation

Prevents duplication across repositories.

Description & Motivation

TensorDict is a dictionary-like class that inherits properties from tensors, such as indexing, shape operations, casting to device, etc. developed by PyTorch.
Currently Fabric does not support them:

from lightning.fabric import Fabric
import torch
from tensordict import TensorDict


def main():
    fabric = Fabric(devices=2, accelerator="cpu", strategy="ddp")
    fabric.launch()
    d = TensorDict({"a": torch.rand(10, 1, 3), "b": torch.rand(10, 2, 7)}, batch_size=[10])
    gathered = fabric.all_gather(d)
    fabric.print(gathered)
    reduced = fabric.all_reduce(d)
    fabric.print(reduced)


if __name__ == "__main__":
    main()

gives the following error:

Traceback (most recent call last):
  File "/home/belerico/Desktop/lightning-apps/lightning/examples/fabric/reinforcement_learning/test.py", line 15, in <module>
    main()
  File "/home/belerico/Desktop/lightning-apps/lightning/examples/fabric/reinforcement_learning/test.py", line 11, in main
    gathered = fabric.all_gather(d)
  File "/home/belerico/Desktop/lightning-apps/lightning/src/lightning/fabric/fabric.py", line 496, in all_gather
    data = convert_to_tensors(data, device=self.device)
  File "/home/belerico/Desktop/lightning-apps/lightning/src/lightning/fabric/utilities/apply_func.py", line 107, in convert_to_tensors
    data = apply_to_collection(data, src_dtype, conversion_func, device=device)
  File "/home/belerico/miniconda3/envs/lightning-ai/lib/python3.9/site-packages/lightning_utilities/core/apply_func.py", line 73, in apply_to_collection
    return elem_type(OrderedDict(out))
  File "/home/belerico/miniconda3/envs/lightning-ai/lib/python3.9/site-packages/tensordict/tensordict.py", line 2888, in __init__
    self._batch_size = self._parse_batch_size(source, batch_size)
  File "/home/belerico/miniconda3/envs/lightning-ai/lib/python3.9/site-packages/tensordict/tensordict.py", line 2905, in _parse_batch_size
    raise ValueError(
ValueError: batch size was not specified when creating the TensorDict instance and it could not be retrieved from source.

Pitch

Let TensorDict be supported by fabric's distributed functions all_gather and all_reduce

Alternatives

No response

Additional context

With the following addition to the https://github.com/Lightning-AI/utilities/blob/main/src/lightning_utilities/core/apply_func.py#L71 method:

+from tensordict import make_tensordict
+from tensordict.tensordict import TensorDictBase

        if isinstance(data, defaultdict):
            return elem_type(data.default_factory, OrderedDict(out))
+      elif isinstance(data, TensorDictBase):
+          return make_tensordict(OrderedDict(out), device=kwargs.get("device", None))  # batch_size is automatically inferred

the above scripts runs without errors:

Initializing distributed: GLOBAL_RANK: 0, MEMBER: 1/2
Initializing distributed: GLOBAL_RANK: 1, MEMBER: 2/2
----------------------------------------------------------------------------------------------------
distributed_backend=gloo
All distributed processes registered. Starting with 2 processes
----------------------------------------------------------------------------------------------------

TensorDict(
    fields={
        a: Tensor(shape=torch.Size([2, 10, 1, 3]), device=cpu, dtype=torch.float32, is_shared=False),
        b: Tensor(shape=torch.Size([2, 10, 2, 7]), device=cpu, dtype=torch.float32, is_shared=False)},
    batch_size=torch.Size([2, 10]),
    device=None,
    is_shared=False)
TensorDict(
    fields={
        a: Tensor(shape=torch.Size([10, 1, 3]), device=cpu, dtype=torch.float32, is_shared=False),
        b: Tensor(shape=torch.Size([10, 2, 7]), device=cpu, dtype=torch.float32, is_shared=False)},
    batch_size=torch.Size([10]),
    device=None,
    is_shared=False)

I don't know if this modification is enough in every case, but I can investigate more if this it'll became a possible feature.

cc @Borda

Originally suggested by @Borda in Lightning-AI/pytorch-lightning#13673 (comment)

🚀 Feature

See title.

Motivation

This feature can further reduce the (GPU) CI time by optimizing the split of standalone tests.

if we somehow sort the test by duration, we can gain a bit more, right bs the batch is long as the slowest test, right?
We could store those metadata on s3 from previous work and re-order. Some extra optim. But not sure we can win that much.
Lightning-AI/pytorch-lightning#13673 (comment)

Pitch

To support this feature, these actions may be useful:

• https://github.com/actions/upload-artifact
• https://github.com/actions/download-artifact
• (haven't explored any in azure pipelines yet..)

Alternatives

Do nothing.

Additional context

This is definitely one of low priority items for now, but just creating this issue as a possible future work to explore.

🚀 Feature

Create a workflow that collects and merges pytest results from CI runs across different operating systems, acclerators and software versions.

With this feature implemented, we will be able to see a merged list of all test cases succeeded/failed/skipped across all CI configurations.

Motivation

We have tests running on across different OS, accelerators and software versions, and currently, each CI run has its own result only, which making it almost impossible to monitor which tests are running or skipped across all such configurations.

Due to this, we've experienced an issue a while ago due to the lack of observability where all of the horovod tests had never run for a long time of period in PL repo.

Pitch

To be explored.
(I guess we could somehow utilise https://github.com/pytest-dev/pytest-reportlog)

Alternatives

To be explored.

Additional context

Codecov automatically merges coverage results uploaded from different CI runs: https://app.codecov.io/gh/Lightning-AI/lightning/
AFAIK, cov result doesn't hold any pytest results, so need to find another way to collect each test case status from different CI settings.

Open for any suggestions 💜

🚀 Feature

Inspired by Lightning-AI/pytorch-lightning#16168 authored by @shenoynikhil, we can include the link checker in this repository, too, so that all our projects benefit from the GH action 🚀

Pitch

Create a reusable workflow file .github/workflows/check-md-links.yml (or a better name).

🚀 List of workflows to replace

Here's a tracking issue for replacing existing workflows with the new reusable workflows across Lightning repositories.

• Lightning-AI/utilities/.github/workflows/clear-cache.yml (requires >v0.3.0)
  • lightning: Lightning-AI/pytorch-lightning#14593
  • lightning-flash:
  • metrics:
  • lightning-bolts:
  • lightning-sandbox:
• Lightning-AI/utilities/.github/workflows/check-schema.yml
  • lightning: Lightning-AI/pytorch-lightning#14469
  • lightning-flash: Lightning-Universe/lightning-flash#1455
  • metrics: Lightning-AI/torchmetrics#1212
  • lightning-bolts: Lightning-Universe/lightning-bolts#868
  • lightning-sandbox:
• ...

🚀 Feature

Follow-up to #55

See title

🐛 Bug

When I'm using torchmetrics, I'm implementing a custom metrics for classification with a nametuple return. before lightning_utilities 0.9.0 it works because the returned nametuple instance was not changed by the apply_func.apply_to_collection. Since this behavior was updated after 0.10.0, I'd like to propose that if apply_to_collection can be updated and still keep the same type.

To Reproduce

Steps to reproduce the behavior...

>>> from torchmetrics.utilities.data import _squeeze_scalar_element_tensor, _squeeze_if_scalar
>>> from collections import namedtuple
>>> import torch
>>> State = namedtuple("State",["gt", "tp", "fp", "tn", "fn"])
>>> state = State(torch.tensor(1), torch.tensor(1) ,torch.tensor(1), torch.tensor(1), torch.tensor(1))
>>> x = _squeeze_if_scalar(state)
>>> x
(tensor(1), tensor(1), tensor(1), tensor(1), tensor(1))

Expected behavior

>>> x = _squeeze_if_scalar(state)
>>> x
State(gt=tensor(1), tp=tensor(1), fp=tensor(1), tn=tensor(1), fn=tensor(1))

Additional context

Proposal

def apply_to_collection(
    data: Any,
    dtype: Union[type, Any, Tuple[Union[type, Any]]],
    function: Callable,
    *args: Any,
    wrong_dtype: Optional[Union[type, Tuple[type, ...]]] = None,
    include_none: bool = True,
    allow_frozen: bool = False,
    **kwargs: Any,
) -> Any:
    if include_none is False or wrong_dtype is not None or allow_frozen is True:
        # not worth implementing these on the fast path: go with the slower option
        return _apply_to_collection_slow(
            data,
            dtype,
            function,
            *args,
            wrong_dtype=wrong_dtype,
            include_none=include_none,
            allow_frozen=allow_frozen,
            **kwargs,
        )
    # fast path for the most common cases:
    if isinstance(data, dtype):  # single element
        return function(data, *args, **kwargs)
    ori_class = data.__class__
    if isinstance(data, list) and all(isinstance(x, dtype) for x in data):  # 1d homogeneous list
        return ori_class(function(x, *args, **kwargs) for x in data)
    if isinstance(data, tuple) and all(isinstance(x, dtype) for x in data):  # 1d homogeneous tuple
        return ori_class(*(function(x, *args, **kwargs) for x in data))
    if isinstance(data, dict) and all(isinstance(x, dtype) for x in data.values()):  # 1d homogeneous dict
        return ori_class(**{k: function(v, *args, **kwargs) for k, v in data.items()})

🚀 Feature

To reduce the confusion on pypi/import/repo names, rename the repo name to something like:

• https://github.com/Lightning-AI/devtools
• https://github.com/Lightning-AI/lightning-devtools

Motivation

Pitch

Alternatives

Additional context

🚀 Feature

https://github.com/Lightning-AI/lightning/blob/f2cacf4b1027a2ce3977e837a7cb1f7f5162698c/src/pytorch_lightning/utilities/model_helpers.py

It's used in PL, app, and torchmetrics

🚀 Feature

Integrate https://github.com/Lightning-AI/lightning/blob/master/src/pytorch_lightning/utilities/rank_zero.py and https://github.com/Lightning-AI/lightning/blob/master/src/pytorch_lightning/utilities/warnings.py

🚀 Feature

Motivation

Seems that particular actions/workflows are not recognized by dependabot and so several of our repo/projects are still using the old version... On the other hand, pin main may have some overhead as we could introduce breaking changes and so broke the particular CI until it is aligned.

So the one global action would aggregate the suggested group of workflows: https://github.com/Lightning-AI/utilities/blob/main/.github/workflows/ci-use-checks.yaml
Also, we can consider based on input/parameter to tun some workflows off 🐿️

Pitch

allow dependabot to pick up whenever we make a new release

Alternatives

switch to use main by default

Additional context

see: https://docs.github.com/en/actions/creating-actions

🐛 Bug

Some of our dataloaders use custom Sequence subclasses, that cause errors in apply_to_collection.

The reason for this is, that these classes won't roundtrip, which is assumed by the implementation of apply_to_collection.

# minimal example
class X(list):
    def __init__(self, x):
        super().__init__(range(x))

data = X(4)

assert data == type(data)(list(data))  # is False, because of how class X's constructor is implemented
                                       # but this is how apply_to_collection handles Sequences

The above is assumed implicitly here:

To Reproduce

See example above.

Expected behavior

If an instance of a sequence subclass can't roundtrip it should just be passed through.

Additional context

N/A

Cheers,
Andreas

🐛 Bug

Version 0.10.1 does not appear at: https://pypi.org/project/lightning-utilities/

Expected behavior

It would be awesome if 0.10.1 could get propagated to PyPI!

Additional context

I maintain a PKGBUILD for Arch Linux that uses PyPI as the source of the latest version of your software. Until the update is pushed to PyPI, I cannot easily update my script to use the latest version of your package.

🚀 Feature

Port apply_to_collection, apply_to_collections, is_namedtuple, and is_dataclass_instance from https://github.com/Lightning-AI/lightning/blob/master/src/pytorch_lightning/utilities/apply_func.py

It's also copied in the app directory