nprint/nprintml

1. nPrintML is a Python command-line package that orchestrates a packet-analysis pipeline rather than implementing the low-level network fingerprinting or ML algorithms itself. Its two main external engines are nPrint for feature generation and AutoGluon for model training.

2. The top-level entry points are nprintml / nml, implemented through src/nprintml/cli.py and __main__.py. manage.py is a separate developer/release entry point used for packaging and maintenance tasks, not for end-user analysis.

3. The core flow is: input PCAPs plus labels in → nPrint feature extraction → label aggregation/alignment → formatted feature datasets → AutoML training and evaluation. The repository is structured to keep these stages separable, which is important for diagramming the boundaries between data ingestion, preprocessing, and learning.

4. The net package is the integration boundary to nPrint itself. net/install.py bootstraps or installs the nPrint executable, while net/execute.py and net/step.py wrap invocation and pipeline-step behavior. In architecture terms, this is the “external process runner” layer that turns the repository into a usable workflow on a local machine or inside Docker.

5. The label package is responsible for turning raw labels into a form that matches the generated packet fingerprints. The presence of aggregator/base.py, aggregator/pcap.py, and aggregator/index.py suggests multiple label sources or grouping strategies, with the package acting as the label-normalization and alignment boundary.

6. The learn package is the training/prediction layer. learn/automl.py integrates AutoGluon, and learn/step.py likely provides pipeline-step orchestration around model fitting, validation, and inference. This layer consumes the feature datasets produced upstream and emits trained models and evaluation outputs downstream.

7. pipeline.py appears to be the composition point tying together the network, label, and learning stages. For an architecture diagram, this is the central workflow coordinator that routes inputs through the appropriate steps depending on whether the user is generating features, training, or running a partial pipeline.

8. The util package holds shared infrastructure used across stages: file-format handling, interface abstractions, I/O, and iteration helpers. util/fileformat.py is especially relevant because the test data shows support for multiple feature representations such as CSV gzip, Parquet, and .fhr, which means format conversion is an architectural concern rather than an implementation detail.

9. The repository is designed as a package under src/, with tests under test/ exercising both the pipeline and CLI behavior. The test/data fixtures include paired PCAPs and labels, plus precomputed feature files, which indicates the intended integration points and expected intermediate artifacts.

10. Docker support is a first-class deployment path but remains an alternate execution environment. image/Dockerfile and the nprintml-docker wrapper script package the same CLI into a container, mainly to simplify setup and isolate dependencies such as nPrint and AutoGluon.

11. CI/CD is lightweight but relevant: GitHub Actions workflows cover test, benchmark, and release. That implies the repo treats reproducibility and command-line behavior as core qualities, with tests centered on end-to-end pipeline execution rather than just isolated library functions.

12. For an architecture diagram, the key boundaries are: user CLI, local orchestration code, external nPrint process, label ingestion/aggregation, dataset formatting, AutoGluon model training, and optional Docker packaging. The project is best understood as a workflow coordinator that glues together existing tools into a no-code traffic-analysis pipeline.