Direction needed: package-first vs standalone rugguard.py release artifact

[leo-guinan]

Context

I opened PR #52 to address the rugguard.py release/download regression from #7.

On reflection, I am not sure the PR is pointed at the right product decision yet. It restores a scripts/rugguard.py shim and adds that file to the GitHub Release assets, which helps repo-checkout usage and keeps current tests/imports working. But if the release asset is downloaded by itself, the shim still depends on the package modules being present, so it does not fully honor the README's advertised path:

curl -OL https://github.com/rugpullnet/solana-rug/releases/latest/download/rugguard.py
python3 rugguard.py token <MINT_ADDRESS> --md

That leaves a choice about the intended pre-1.0 contract.

Option A: package-first pre-1.0

Treat solana-rug as a normal Python package/CLI project and remove or revise the single-file release promise.

Suggested direction:

• Remove/update the releases/latest/download/rugguard.py install path from README/site docs.
• Stop treating rugguard.py as a standalone release artifact.
• Keep supported install paths as PyPI and source checkout:
  • pip install solana-rug
  • solana-rug token ...
  • python3 scripts/solana-rug.py ... from a checkout
• Let PR fix: restore rugguard.py release shim #52 be reduced or dropped depending on whether a repo-local compatibility shim is still wanted.

Why this may be right:

• Pre-1.0 internal structure can move quickly.
• The package refactor is cleaner for maintainability.
• Avoids carrying a generated/bundled single-file artifact.

Tradeoff:

• Weakens the project's current trust/auditability story. The README currently says the source is a single auditable Python file and the direct release download is a no-install path.

Option B: preserve the single-file trust surface

Keep the README promise and make rugguard.py a real standalone release artifact again.

Suggested direction:

• Generate or maintain a standalone rugguard.py that works when downloaded alone.
• Attach that real standalone file to GitHub Releases.
• Add a release/CI check that copies only rugguard.py into a temp directory and runs:

python3 rugguard.py --help

Optionally also smoke-test a known mint, though live public RPC may be flaky:

python3 rugguard.py token DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263 --json

Why this may be right:

• Matches the advertised install command.
• Preserves the "single auditable Python file / no opaque dependencies" trust posture.
• Especially valuable for security/rug-check tooling, where users may not want to install a package just to inspect one token.

Tradeoff:

• More release machinery.
• Need to avoid drift between package modules and the standalone artifact.

Question

Which contract do you want for pre-1.0?

1. Package-first: update docs and make PyPI/source checkout the supported path.
2. Single-file-first: keep the direct rugguard.py download promise and require the release artifact to work standalone.

Once you choose, I can update or withdraw PR #52 accordingly instead of silently locking in the wrong compatibility surface.