nsploit/hooks, branch v0.2 Process interaction tool for software exploitation Dynamically source version in toml from git 2023-02-24T03:52:57+00:00 dusoleil howcansocksbereal@gmail.com 2023-02-23T10:29:21+00:00 9f4648dae644f2fb9deb4c68859d6cdfd0bc0530 Instead of hard-coding the version into the pyproject.toml, we can dynamically source it at build time. Ideally, we want to use git describe as a single authority source on the version. The version is stored in sploit.__version__ and can be consumed during sploit runtime or during a build/package to populate the project's core metadata version in the toml file. hatchling provides a tool.hatch.version plugin that can read out the variable during a build/package. Because this variable is populated from a git command, if the source tree isn't in a git repo, it will fail. In this case, sploit will report a PEP 440 compliant fake version "0+unknown.version" to let the user know. Because a packaged distribution doesn't exist in a git repo, we want to bake in the version at build time into the package. hatchling provides a plugin to help with this, but it had some technical limitations that didn't quite work for our use case. Instead, I added a custom build hook which will take the version sourced from the package (and by proxy the git command), and overwrite the __init__.py with a hard-coded version in the __version__ variable. This means that built/packaged distributions of this project will have a fixed version hard-coded in rather than dynamically sourcing from git. The build hook operates just before the build executes. It seems that most build/packager front-ends (e.g. build, pip) will just run it in the current source tree rather than making a temp copy. This means that when we modify the __init__.py, it is modifying our git tree. Ideally, we want this to be restored at the end of the build. The build hook interface allows us to write a hook that happens after the build, but it won't run in the case of a crash or failed build. Instead, I added a custom solution to this using a member variable deconstructor. If the build ends in any way, the original contents of __init__.py are written back out. Signed-off-by: dusoleil <howcansocksbereal@gmail.com> Reviewed-by: Malfurious <m@lfurio.us> 
Instead of hard-coding the version into the pyproject.toml, we can
dynamically source it at build time.  Ideally, we want to use git
describe as a single authority source on the version.  The version is
stored in sploit.__version__ and can be consumed during sploit runtime
or during a build/package to populate the project's core metadata
version in the toml file.

hatchling provides a tool.hatch.version plugin that can read out the
variable during a build/package.  Because this variable is populated
from a git command, if the source tree isn't in a git repo, it will
fail.  In this case, sploit will report a PEP 440 compliant fake version
"0+unknown.version" to let the user know.

Because a packaged distribution doesn't exist in a git repo, we want to
bake in the version at build time into the package.  hatchling provides
a plugin to help with this, but it had some technical limitations that
didn't quite work for our use case.  Instead, I added a custom build
hook which will take the version sourced from the package (and by proxy
the git command), and overwrite the __init__.py with a hard-coded
version in the __version__ variable. This means that built/packaged
distributions of this project will have a fixed version hard-coded in
rather than dynamically sourcing from git.

The build hook operates just before the build executes.  It seems that
most build/packager front-ends (e.g. build, pip) will just run it in the
current source tree rather than making a temp copy.  This means that
when we modify the __init__.py, it is modifying our git tree.  Ideally,
we want this to be restored at the end of the build.  The build hook
interface allows us to write a hook that happens after the build, but it
won't run in the case of a crash or failed build.  Instead, I added a
custom solution to this using a member variable deconstructor.  If the
build ends in any way, the original contents of __init__.py are written
back out.

Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
Reviewed-by: Malfurious <m@lfurio.us>