WIP custom man sections

man/eth-monitor.custom.groff

@@ -0,0 +1,27 @@
+.SH DEFINING FILTERS
+
+A python module used for filter must fulfill two conditions:
+
+.IP
+1. It must provide a class named \fIFilter\fP in the package base namespace.
+.IP
+2. The \fIFilter\fP class must include a method named \fIfilter\fP with the signature \fIdef filter(self, conn, block, tx, db_session=None)\fP. 
+
+Filters will strictly be executed in the order which they are defined on the command line.
+
+
+.SH SYNCING
+When a sync is initiated, the state of this sync is persisted. This way, previous syncs that did not complete for some reason will be resumed where they left off.
+.P
+A special sync type \fB--head\fP starts syncing at the current head of the chain, and continue to sync until interrupted. When resuming sync, a new sync range between the current block head and the block height at which the previous \fB--head\fP sync left off will automatically be created.
+.P
+Syncs can be forced to (re)run for ranges regardless of previous state by using the \fB--single\fP option. However, there is no protection in place from preventing code filters from being executed again on the same transaction when this is done.
+
+
+.SH RENDERING
+
+
+
+.SH FURTHER READING
+
+Refer to the \fBchainsyncer\fP chapter n \fIinfo chaintool\fP for in-depth information on the subjects of syncing and filtering.

man/eth-monitor.head.groff

@@ -4,21 +4,31 @@
 eth-monitor \- Cache, index and monitor transactions with an EVM node rpc
 
 .SH SYNOPSIS
-.P
+.SY eth-monitor
-\fBeth-monitor\fP [ --skip-history ] [ --single ] [ p \fIeth_provider\fP ] [ --includes-file \fIfile\fP ] 
+[ --skip-history ] [ --single ] [ p \fIeth_provider\fP ] [ --includes-file \fIfile\fP ] 
-.P
+.YS
-\fBeth-monitor\fP [ --skip-history ] [ --single ] [ p \fIeth_provider\fP ] [ --excludes-file \fIfile\fP ] [ --include-default ] 
+.SY eth-monitor
+[ --skip-history ] [ --single ] [ p \fIeth_provider\fP ] [ --excludes-file \fIfile\fP ] [ --include-default ] 
+.YS
 
 
 .SH DESCRIPTION
+.P
+The \fBeth-monitor\fP has fulfills three distinct but related functions:
+.IP
+1. A customizable view of on transactions of interest.
+.IP
+2. A block and transaction cache.
+.IP
+3. Arbitrary code executions using a transaction (and its block) as input.
+
 .P
 Using an EVM RPC endpoint, the \fBeth-monitor\fP tool will retrieve blocks within a given range and provides arbitrary processing of each transaction. Sync behavior is controlled using the \fB--offset\fP, \fB--until\fP and \fB--head\fP options. \fBSee EXAMPLES\fP on sync example usage.
 .P
-Processing is done by python modules implementing a filter interface, specified by the \fB--filter\fP option. See \fBinfo eth-monitor\fP for information on how to write filters.
+Processing is done by python modules implementing a filter interface. Filter modules are specified by the \fB--filter\fP option, which can be defined multiple times. See \fBDEFINING FILTERS\fP for details.
 .P
-Each chain spec persists its own sync state. E.g. if a historical sync between blocks 100 and 200 was executed against chain \fIevm:foo:42:bar\fP and halted at block 150, then next execution will resume at this block height. The state of which filters were executed for the last transaction processed is also kept. See \fBSYNCING\fP below for more details.
+Each chain spec persists its own sync state. E.g. if a historical sync between blocks 100 and 200 was executed against chain \fIevm:foo:42:bar\fP and halted at block 150, then next execution will resume at this block height. The state of which filters were executed for the last transaction processed is also kept. The \fB--single\fP option can be used to override this behavior. See \fBSYNCING\fP below for more details.
 .P
-Syncs can be forced to (re)run for ranges regardless of previous state by using the \fB--single\fP option. However, there is no protection in place from preventing code filters from being executed again on the same transaction when this is done.
 .P
 By default, no transactions are matched, and input and output addresses to match against transactions need to be explicitly specified. This behavior can be reversed with the \fB--include-default\fP option. Addresses to match are defined using the \fB--input\fP and \fB--output\fP options, and/or by file using the \fB--includes-file\fP and \fB--excludes-file\fP options. Addresses specified multiple times will be deduplicated.
 .P

setup.cfg

@@ -0,0 +1,40 @@
+[metadata]
+name = eth-monitor
+version = 0.1.0a1
+description = Monitor and cache transactions using match filters
+author = Louis Holbrook
+author_email = dev@holbrook.no
+url = https://git.defalsify.org/eth-monitor
+keywords =
+	dlt
+	blockchain
+	cryptocurrency
+	ethereum
+classifiers =
+	Programming Language :: Python :: 3
+	Operating System :: OS Independent
+	Development Status :: 3 - Alpha
+	Topic :: Software Development :: Libraries
+	Environment :: Console
+	Intended Audience :: Developers
+	License :: OSI Approved :: GNU General Public License v3 or later (GPLv3+)
+	Topic :: Internet
+#	Topic :: Blockchain :: EVM
+license = GPL3
+licence_files =
+	LICENSE
+
+[options]
+include_package_data = True
+python_requires = >= 3.7
+packages = 
+	eth_monitor
+	eth_monitor.importers
+	eth_monitor.filters
+	eth_monitor.store
+	eth_monitor.runnable
+	eth_monitor.mock
+
+[options.entry_points]
+console_scripts =
+	eth-monitor-sync = eth_monitor.runnable.sync:main

setup.py

@@ -0,0 +1,28 @@
+from setuptools import setup
+import configparser
+import os
+
+
+requirements = []
+f = open('requirements.txt', 'r')
+while True:
+    l = f.readline()
+    if l == '':
+        break
+    requirements.append(l.rstrip())
+f.close()
+
+test_requirements = []
+f = open('test_requirements.txt', 'r')
+while True:
+    l = f.readline()
+    if l == '':
+        break
+    test_requirements.append(l.rstrip())
+f.close()
+
+
+setup(
+        install_requires=requirements,
+        tests_require=test_requirements,
+    )