@weskamm Could you please review this PR?

@weskamm Could you please take a look? If there are changes that need to be made I will fix them right away.

Looks good to me, thanks for the fixup.

We are reverting this PR because it was causing problems in production - especially with existing caches. I think we need backwards compatibility and unit tests to assure that everything works correctly.

@simonseyock What are the problems that this causes? I will work on the issues ASAP.

There was the problem that mapproxy did only return blank images for caches that were created before the update.

In the PR itself I see this problems:

1. It does not introduce a test that demonstrates the failing case
2. In the existing tests, it is ensured that every tile is stored with a .png ending. I do not know exactly why that is, but it feels not right to me. See

   mapproxy/mapproxy/test/system/test_mixed_mode_format.py

   Line 121 in a73fe7f

   assert cache_dir.join(

3. The new tile_location function has this code:

        if self.is_mixed:
            location = self._tile_location(tile, self.cache_dir, 'jpeg', create_dir=create_dir, dimensions=dimensions)
            if not os.path.exists(location):
                tile.location = None
                location = self._tile_location(tile, self.cache_dir, 'png', create_dir=create_dir, dimensions=dimensions)

This will never cause a file with .jpeg to be created. Might be intended so
4. In the tile_location function of the file cache there is code that does nothing. This was there before and maybe is unrelated to the problem:

So, if MapProxy should supported reading caches that mix .jpeg and .png files I think it should also create .jpeg and .png files. Furthermore we need to ensure that old caches are still usable.

I do not have a reproducible example, but I hope to get one.

We reverted the commit because we needed a clean working release before merging all of the linting and deprecation issues.

There was the problem that mapproxy did only return blank images for caches that were created before the update.

In the PR itself I see this problems:

1. It does not introduce a test that demonstrates the failing case
2. In the existing tests, it is ensured that every tile is stored with a .png ending. I do not know exactly why that is, but it feels not right to me. See

   mapproxy/mapproxy/test/system/test_mixed_mode_format.py

   Line 121 in a73fe7f

   assert cache_dir.join(

3. The new tile_location function has this code:

        if self.is_mixed:
            location = self._tile_location(tile, self.cache_dir, 'jpeg', create_dir=create_dir, dimensions=dimensions)
            if not os.path.exists(location):
                tile.location = None
                location = self._tile_location(tile, self.cache_dir, 'png', create_dir=create_dir, dimensions=dimensions)

This will never cause a file with .jpeg to be created. Might be intended so 4. In the tile_location function of the file cache there is code that does nothing. This was there before and maybe is unrelated to the problem:

mapproxy/mapproxy/cache/file.py

Line 55 in a73fe7f

cache_dir = os.path.join(self.cache_dir, '_'.join(dimensions_str))

So, if MapProxy should supported reading caches that mix .jpeg and .png files I think it should also create .jpeg and .png files. Furthermore we need to ensure that old caches are still usable.

Thank you very much for your review! I will add a failing test as you requested and fix the existing tests.
As for your third point, I see that when dealing with file caches I have ignored the create_dir parameter that indicates wanting to store a tile instead of just getting it from the cache. I will look into the issue for S3 and azureblob as well.
I agree that storing mixed tiles is what was intended.