package tool & avoid exec

[tharvik]

• don't exec given spec but use a callable instead
  • specs now import from klint
  • still a __symbex__ for the state but as a singleton :shrug:
• add pyproject.toml (another pkg system :roll_eyes: but standard looking enough), get rid of pip specifics
  • install a klint executable
• publish tool to pypi
  • it works in the pypi test: https://test.pypi.org/project/klint
  • you should set a repo secret called PYPI_API_TOKEN for GitHub Actions
  • will only publish on tag (use classic semver naming ~= v\d+(\.\d+){2})
• also
  • bunch of types added, requires python 3.10 for the new type objects: typing.List[int] -> list[int]
  • now direclty runnable via python python -m klint with the same interface as the cmdline
  • split klint/verif/symbex in various mods

[SolalPirelli]

Looks great! Sorry I didn't see this earlier, somehow I'm not getting notifications for this repo despite watching this (this PR says "you're receiving notifications", but... I am not), don't hesitate to assign me to review or ping me here or by email.

Just one question: how does the new packaging system work in terms of referring to specific versions of our dependencies? angr has had breaking changes in the past (while I was developing this), so I'm a bit wary of using "whatever their latest version is".

[tharvik]

how does the new packaging system work in terms of referring to specific versions of our dependencies?

it doesn't, it uses the latest (compatible) version. should the need arise, we can skip versions by depending on angr <2.0,!=1.2, or add a constraint files if we want repeatable installs

angr has had breaking changes in the past (while I was developing this), so I'm a bit wary of using "whatever their latest version is".

I agree, having klint break for simply pulling the wrong version of angr can be annoying, but it's needed IMHO. let me explain: if we stick to a specific version, we'll probably end up never bumping theses, as we would need to actively check for new versions. as the more we wait, the more we drift from the API changes of angr that accumulates a technical debt and that's not wanted. morever, when angr publishes a new broken version, it is only transient, as someone (us?) will tell them that is not working as expected, then the latest angr version will be fixed. now, if we want to make sure that it doesn't break for the users, we can add a constraint file during the packaging process, taking what was used by the CI and freeze it. this way, we ensure that the repo stays up-to-date and that users should not encounter breakage. anyways, that's my point, but your code, your call :)

[SolalPirelli]

How about we leave it using the latest versions, but we write down somewhere a list of "known good" versions? (e.g., whatever a constraint file looks like if you produce it right now) that way if it doesn't get updated someone can still use it without spending time finding what versions it was supposed to work with

[tharvik]

alright, let's do that.

I added the tool/constraints file, a make target called tool-constraints to generate it and a quick explaination in the tool/readme. we are now responsible to update it when we see fit.