dev-python/hunter: new package, add 3.4.3-r1, 3.5.1

This commit is contained in:
Alarig Le Lay 2023-01-31 00:28:26 +01:00
parent 97c87334df
commit 6f949de01e
Signed by: alarig
GPG key ID: 7AFE62C6DF8BCDEC
4 changed files with 223 additions and 0 deletions

View file

@ -0,0 +1,2 @@
DIST hunter-3.4.3.gh.tar.gz 538017 BLAKE2B 92ad2b653d0285059ea2f005c6ba9564f357e1ea438a0fe30087f88efa202aaa504bad65985a88484cf7178c24432ac44705098dabc2667328c71e0ee38f718c SHA512 921bb48ac5d384977908dda060e178e623eb7c1e4298cbf3c0a273cab23695f2a2a60221afb257e54cd144399d2b3b55b80ae9a2c7f71ba452894cc86112d5f7
DIST hunter-3.5.1.gh.tar.gz 543137 BLAKE2B a06966f78fd442231c08e2aafe57702f7cc16e5db6aa9a1da7288e4a3a05ff9db3dfc49352641610ade31cb967996c3add64f07ddf637f46e5d269e9d0363a9f SHA512 2c302fa8b88c07be5361f11d8c250c5673be9dc691df9e966959eed45eaf0a8499ae8a6381256d83ab7219c818ed981628fb3299ef5d17d7b1d95c43a2fc63a7

View file

@ -0,0 +1,69 @@
# Copyright 1999-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
EAPI=8
PYTHON_COMPAT=( python3_{8..10} )
DISTUTILS_USE_PEP517=setuptools
inherit distutils-r1
DESCRIPTION="Hunter is a flexible code tracing toolkit"
HOMEPAGE="
https://github.com/ionelmc/python-hunter
https://pypi.org/project/hunter/
"
SRC_URI="https://github.com/ionelmc/python-${PN}/archive/v${PV}.tar.gz -> ${P}.gh.tar.gz"
S="${WORKDIR}/python-${P}"
LICENSE="BSD-2"
SLOT="0"
KEYWORDS="~amd64"
# python-hunter only works if deps are vendored (some .pth stuff)
#RDEPEND="
#>=dev-python/colorama-0.4.4[${PYTHON_USEDEP}]
#dev-python/cymem[${PYTHON_USEDEP}]
#"
DEPEND="
dev-python/cython[${PYTHON_USEDEP}]
"
BDEPEND="
>=dev-python/setuptools_scm-3.3.1[${PYTHON_USEDEP}]
test? (
dev-python/aspectlib[${PYTHON_USEDEP}]
dev-python/ipdb[${PYTHON_USEDEP}]
dev-python/manhole[${PYTHON_USEDEP}]
dev-python/process-tests[${PYTHON_USEDEP}]
dev-python/pytest-benchmark[${PYTHON_USEDEP}]
dev-python/six[${PYTHON_USEDEP}]
dev-python/toml[${PYTHON_USEDEP}]
)
" # toml is an indirect dependency (needed by ipdb)
DOCS=( AUTHORS.rst CHANGELOG.rst README.rst )
EPYTEST_IGNORE=( test_remote.py )
EPYTEST_DESELECT=(
tests/test_tracer.py::test_source_cython
tests/test_tracer.py::test_fullsource_cython
)
distutils_enable_tests pytest
distutils_enable_sphinx docs ">=dev-python/sphinx-py3doc-enhanced-theme-2.3.2"
src_unpack() {
default
cp -a "${S}" tests_package || die
mv -f tests_package/tests/setup.py tests_package || die
}
python_test() {
cp -a "${BUILD_DIR}"/{install,test} || die
local -x PATH=${BUILD_DIR}/test/usr/bin:${PATH}
cd "${WORKDIR}"/tests_package >/dev/null || die
distutils_pep517_install "${BUILD_DIR}"/test
cd ./tests || die
epytest
}

View file

@ -0,0 +1,79 @@
# Copyright 1999-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
EAPI=8
PYTHON_COMPAT=( python3_{9..11} )
DISTUTILS_USE_PEP517=setuptools
inherit distutils-r1 multiprocessing
DESCRIPTION="Hunter is a flexible code tracing toolkit"
HOMEPAGE="
https://github.com/ionelmc/python-hunter
https://pypi.org/project/hunter/
"
SRC_URI="https://github.com/ionelmc/python-${PN}/archive/v${PV}.tar.gz -> ${P}.gh.tar.gz"
S="${WORKDIR}/python-${P}"
TEST_S="${S}_test"
LICENSE="BSD-2"
SLOT="0"
KEYWORDS="~amd64"
BDEPEND="
dev-python/cython[${PYTHON_USEDEP}]
>=dev-python/setuptools_scm-3.3.1[${PYTHON_USEDEP}]
test? (
dev-python/aspectlib[${PYTHON_USEDEP}]
dev-python/ipdb[${PYTHON_USEDEP}]
dev-python/manhole[${PYTHON_USEDEP}]
dev-python/process-tests[${PYTHON_USEDEP}]
dev-python/pytest-benchmark[${PYTHON_USEDEP}]
dev-python/six[${PYTHON_USEDEP}]
sys-devel/gdb
)
"
DOCS=( AUTHORS.rst CHANGELOG.rst README.rst )
EPYTEST_DESELECT=(
# broken
tests/test_tracer.py::test_source_cython
tests/test_tracer.py::test_fullsource_cython
# too unstable
tests/test_remote.py
)
distutils_enable_tests pytest
distutils_enable_sphinx docs \
">=dev-python/sphinx-py3doc-enhanced-theme-2.3.2"
src_unpack() {
default
cp -a "${S}" "${TEST_S}" || die
mv -f "${TEST_S}"/tests/setup.py "${TEST_S}"/setup.py || die
}
src_prepare() {
default
find . -name '*.c' -delete || die "removing csources failed"
}
python_compile() {
distutils-r1_python_compile
if use test; then
einfo " Building tests"
cd "${TEST_S}" || die
esetup.py build_ext -j $(makeopts_jobs) --inplace
fi
}
python_test() {
cd "${TEST_S}"/tests || die
epytest
}

View file

@ -0,0 +1,73 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
<maintainer type="person">
<email>lssndrbarbieri@gmail.com</email>
<name>Alessandro Barbieri</name>
</maintainer>
<longdescription lang="en">
Hunter is a flexible code tracing toolkit, not for measuring coverage, but for debugging, logging, inspection and other nefarious purposes. It has a simple Python API, a convenient terminal API and a CLI tool to attach to processes.
Design notes
Hunter doesn't do everything. As a design goal of this library some things are made intentionally austere and verbose (to avoid complexity, confusion and inconsistency). This has few consequences:
There are Operators but there's no negation operator. Instead you're expected to negate a Query object, eg: ~Q(module='re').
There are no specialized operators or filters - all filters behave exactly the same. For example:
No filter for packages. You're expected to filter by module with an operator.
No filter for arguments, return values or variables. You're expected to write your own filter function and deal with the problems of poking into objects.
Layering is minimal. There's are some helpers that do some argument processing and conversions to save you some typing but that's about it.
The library doesn't try to hide the mechanics of tracing in Python - it's 1:1 regarding what Python sends to a trace function if you'd be using sys.settrace.
Doesn't have any storage. You are expected to redirect output to a file.
You should look at it like it's a tool to help you understand and debug big applications, or a framework ridding you of the boring parts of settrace, not something that helps you learn Python.
FAQ
Why not Smiley?
There's some obvious overlap with smiley but there are few fundamental differences:
Complexity. Smiley is simply over-engineered:
It uses IPC and a SQL database.
It has a webserver. Lots of dependencies.
It uses threads. Side-effects and subtle bugs are introduced in your code.
It records everything. Tries to dump any variable. Often fails and stops working.
Why do you need all that just to debug some stuff in a terminal? Simply put, it's a nice idea but the design choices work against you when you're already neck-deep into debugging your own code. In my experience Smiley has been very buggy and unreliable. Your mileage may vary of course.
Tracing long running code. This will make Smiley record lots of data, making it unusable.
Now because Smiley records everything, you'd think it's better suited for short programs. But alas, if your program runs quickly then it's pointless to record the execution. You can just run it again.
It seems there's only one situation where it's reasonable to use Smiley: tracing io-bound apps remotely. Those apps don't execute lots of code, they just wait on network so Smiley's storage won't blow out of proportion and tracing overhead might be acceptable.
Use-cases. It seems to me Smiley's purpose is not really debugging code, but more of a "non interactive monitoring" tool.
In contrast, Hunter is very simple:
Few dependencies.
Low overhead (tracing/filtering code has an optional Cython extension).
No storage. This simplifies lots of things.
The only cost is that you might need to run the code multiple times to get the filtering/actions right. This means Hunter is not really suited for "post-mortem" debugging. If you can't reproduce the problem anymore then Hunter won't be of much help.
Why not pytrace?
Pytrace is another tracer tool. It seems quite similar to Smiley - it uses a sqlite database for the events, threads and IPC, thus it's reasonable to expect the same kind of problems.
Why not PySnooper or snoop?
snoop is a refined version of PySnooper. Both are more suited to tracing small programs or functions as the output is more verbose and less suited to the needs of tracing a big application where Hunter provides more flexible setup, filtering capabilities, speed and brevity.
Why not coverage?
For purposes of debugging coverage is a great tool but only as far as "debugging by looking at what code is (not) run". Checking branch coverage is good but it will only get you as far.
From the other perspective, you'd be wondering if you could use Hunter to measure coverage-like things. You could do it but for that purpose Hunter is very "rough": it has no builtin storage. You'd have to implement your own storage. You can do it but it wouldn't give you any advantage over making your own tracer if you don't need to "pre-filter" whatever you're recording.
In other words, filtering events is the main selling point of Hunter - it's fast (cython implementation) and the query API is flexible enough.
</longdescription>
<upstream>
<remote-id type="github">ionelmc/python-hunter</remote-id>
<remote-id type="pypi">hunter</remote-id>
</upstream>
</pkgmetadata>