Migrate project towards cutting edge 2025 tooling and methodology

[fkromer]

• restructure project to enable clean Python library builds
• replace poetry with uv
  • enable usage of uv workspaces
  • add CycloneDX sbom output
• pyproject.toml
  • added state of the art dev tools (test framework, static analysis, type checking)
  • single source of package build
  • single source of Python dependencies (requirements.txt files generated from it)
• fix and extend contribution docs
• remove obsolete files
• (backwards compatible Dockerfile adjustments... Dockerfile setup still not working, adding a devcontainers Dockerfile would make more sense anyways I guess... Dockerfile for report and diagram generation are usually maintained by pytm users due to "own" container security analysis tools)
• (Makefile setup not tested... is obsolete as soon as devcontainer Dockerfile is available anyways I guess)

[fkromer]

Heading towards world domination @izar 😉

[fkromer]

Merging #299 later on will be straightforward.

[fkromer]

The data contained in src/pytm/images and threatlib/threats.json needs to be considered as explicit data still potentially.

[izar]

Sorry it took me so long to get to this review. Life happens.
I am a fan of UV as well, but I am reticent of removing poetry altogether, if only because it makes publishing to pypi much cleaner and easier. I haven't yet used "uv publish", I'll check it out as soon as time permits. Do you think it would be possible to have both coexist meanwhile?

Also, any chance you could break this into functional and format changes? Also, devcontainers is ... flashy, but some of us old schoolers still like their "make world" approach :)

[izar]

How do we want to solve the conflicts here ?

[fkromer]

@izar Not sure what you mean with "conflicts"? Pipelines are all passing https://github.com/OWASP/pytm/pull/305/checks...

As stated by @Alicipy in #331 related to maintaining backwards compatibility it might be better not to migrate from pytm to src/pytm source code structure. This prevents from forcing people migrating own, custom libraries (depending on pytm project structure) to this new structure potentially. Remaining topics I've commented on in #331 already. As soon as #331 is merged most important stuff is done... To resolve #302 one option is to use uv workspaces that might depend on a src/pytm based project structure. But this limitation could be addresses differently potentially as well (extension API, ...). devcontainers is an optional nice to have not super important.