Cleanup Texture2DConverter and fix typos in pyproject.toml

[isHarryh]

Summary

This PR does some minor changes to Texture2DConverter.

• platform_blob can be List[int] in newer version of Unity, instead of only bytes.
• One platform_blob type hint still uses bytes, now corrected to List[int].
• if TYPE_CHECKING: assert xxx is not None seems redundant, now removed if.
• Pre-converts platform to BuildTarget enum.
• Wraps swizzle texture_format conversion into TextureSwizzler.
• Simplifies the redundant if-statements in image_to_texture2d.
• Optimizes docstrings and typos.

Along with two typo fixes in the pyproject.toml:

• Fixes the invalid license field in pyproject.toml which causes CodeQL failing.
• Fixes the typo of the keyword data-minig in pyproject.toml.

[K0lb3]

Sorry that I'm only replying now.

I will be blunt, I don't really see the point of this PR.

The typo fixes, doc string adjustments and the BC format collapsing are okay, but that's it.

TextureSwizzler.get_corrected_texture_format is basically a one-time use function,
which only adds a layer of indirection without any benefit, as at one of the two places where it's being used, the same check has to be done again anyway.

TextureSwizzler.PlatformBlobType is also not really useful.
The usage of bytes from before was actually wrong, as the platformblob type is defined by the Texture2D field of it, so just List[int] is enough.

The platform type also doesn't have to be narrowed down to BuildTarget,
as the only use of platform is in an equality check, which works just fine with an int as well.

[isHarryh]

Apologies - I didn’t fully considered the current needs, so I’ve decided to go ahead and revert the 3 changes you mentioned, to narrow the PR to only typo fixes.

My initial intention with these changes was to centralize the logic and make the code more readable in the long run. But I understand that, the added abstraction doesn’t bring enough value and instead introduces unnecessary complexity.

Thanks again for your constructive feedback - it’s much appreciated.

[isHarryh]

This PR now contains:

1. Typo and docstring adjustments.
2. BC format if-statements collapsing.

with some new changes:

3. One platform_blob type hint still uses bytes, now corrected to List[int].
4. if TYPE_CHECKING: assert xxx is not None seems redundant, now removed if.
5. Fixes the invalid license field in pyproject.toml which causes CodeQL failing.
6. Fixes the typo of the keyword data-minig in pyproject.toml.

[K0lb3]

Directly writing a SPDX license expression is the new expected value for the license field, see Writing your pyproject.toml - Python Packaging User Guide.

[isHarryh]

Yes, PEP 639 adopted SPDX format, and toml-table based format is deprecating. But sadly for Python<=3.8/setuptools<=v75.3.2 , build will fail.

I have reverted this line of change, and you can decide how to deal with it.

[K0lb3]

Thanks for clarifying that.
I guess that I will simply have to set the min version to 3.9.

3.7 is already broken due to typing_extensions used in some dependency, so might as well remove 3.8 support as well.
As there are already breaking commits up, this can come with the next minor update.

[K0lb3]

As indicated in that issue, I will simply drop the commit that changed the version, while adding a new one for the setuptools max version.

[isHarryh]

Imo, we might consider delaying the restriction on the maximum version of setuptools, as some projects that currently rely on the latest version of setuptools may encounter dependency resolution errors.

[K0lb3]

I will simply set to to a possible future version, going by the current release cadence for now, as I would probably forget about it otherwise.

You have a pretty good point there that I didn't even think about.
This makes the whole issue very tricky.

I prefer to support old versions as long as it doesn't take too much effort to support them,
and there are certainly options to work around the issue, just that they are a bit too hacky imo.

[K0lb3]

Thanks for the changes and the effort.
I will re-check your PR at Monday, but so far it looks fine now.

My handling of OOP and abstraction in UnityPy, and well, overall, is probably pretty non-standard, and might appear a bit arbitrary, which I'm sorry for.
Imo code should be directly readable without having to follow dozens of deep trails through "useless" OOP patterns to understand what's going on exactly.
So, based on that, I think that only either very long condition specific code, "tricky" code, or often re-used code should be "extracted" from the source where it actually gets used.
Ofc everyone has a different take on what's readable, to say nothing about my vague own conditions, but well, being able to decide that for a project is one of the advantages of owning it in exchange for maintaining it.

Anyway,
regarding the long term, I plan to make UnityPy more modular, moving all the exporters and most helpers into separate projects.
UnityPy itself will then only handle the Unity asset parsing and saving, as well as the object loading and saving.
The processing of the objects will then be in the hands of "other" projects, which I plan to name "exchange", so export and import.
That's also the reason the classes/legacy_patch is named the way it is.