container-workflow-tool fails to build with Python 3.13.0a5.

Example:

___________ ERROR at teardown of TestRebuilder.test_get_set_workdir ____________

self = <tests.test_rebuilder.TestRebuilder object at 0x7ff037d43620>

    def teardown_method(self):
>       self.ir.clear_cache()

tests/test_rebuilder.py:44: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
container_workflow_tool/main.py:418: in clear_cache
    shutil.rmtree(tmp, ignore_errors=True)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

path = None, ignore_errors = True, onerror = None

    def rmtree(path, ignore_errors=False, onerror=None, *, onexc=None, dir_fd=None):
        """Recursively delete a directory tree.
    
        If dir_fd is not None, it should be a file descriptor open to a directory;
        path will then be relative to that directory.
        dir_fd may not be implemented on your platform.
        If it is unavailable, using it will raise a NotImplementedError.
    
        If ignore_errors is set, errors are ignored; otherwise, if onexc or
        onerror is set, it is called to handle the error with arguments (func,
        path, exc_info) where func is platform and implementation dependent;
        path is the argument to that function that caused it to fail; and
        the value of exc_info describes the exception. For onexc it is the
        exception instance, and for onerror it is a tuple as returned by
        sys.exc_info().  If ignore_errors is false and both onexc and
        onerror are None, the exception is reraised.
    
        onerror is deprecated and only remains for backwards compatibility.
        If both onerror and onexc are set, onerror is ignored and onexc is used.
        """
    
        sys.audit("shutil.rmtree", path, dir_fd)
        if ignore_errors:
            def onexc(*args):
                pass
        elif onerror is None and onexc is None:
            def onexc(*args):
                raise
        elif onexc is None:
            if onerror is None:
                def onexc(*args):
                    raise
            else:
                # delegate to onerror
                def onexc(*args):
                    func, path, exc = args
                    if exc is None:
                        exc_info = None, None, None
                    else:
                        exc_info = type(exc), exc, exc.__traceback__
                    return onerror(func, path, exc_info)
    
        if _use_fd_functions:
            # While the unsafe rmtree works fine on bytes, the fd based does not.
            if isinstance(path, bytes):
                path = os.fsdecode(path)
            # Note: To guard against symlink races, we use the standard
            # lstat()/open()/fstat() trick.
            try:
>               orig_st = os.lstat(path, dir_fd=dir_fd)
E               TypeError: lstat: path should be string, bytes or os.PathLike, not NoneType


ERROR tests/test_rebuilder.py::TestRebuilder::test_do_images - TypeError: lst...
ERROR tests/test_rebuilder.py::TestRebuilder::test_get_set_workdir - TypeErro...
ERROR tests/test_rebuilder.py::TestRebuilder::test_set_repo_url - TypeError: ...
================= 28 passed, 10 deselected, 3 errors in 0.70s ==================

https://docs.python.org/3.13/whatsnew/3.13.html

For the build logs, see:
https://copr-be.cloud.fedoraproject.org/results/@python/python3.13/fedora-rawhide-x86_64/07211459-container-workflow-tool/

For all our attempts to build container-workflow-tool with Python 3.13, see:
https://copr.fedorainfracloud.org/coprs/g/python/python3.13/package/container-workflow-tool/

Testing and mass rebuild of packages is happening in copr.
You can follow these instructions to test locally in mock if your package builds with Python 3.13:
https://copr.fedorainfracloud.org/coprs/g/python/python3.13/

Let us know here if you have any questions.

Python 3.13 is planned to be included in Fedora 41.
To make that update smoother, we're building Fedora packages with all pre-releases of Python 3.13.
A build failure prevents us from testing all dependent packages (transitive [Build]Requires),
so if this package is required a lot, it's important for us to get it fixed soon.

We'd appreciate help from the people who know this package best,
but if you don't want to work on this now, let us know so we can try to work around it on our side.