Remove framework/libraries that are defunct or with no contributions in X amount of years

[x80486]

[avelino]

@x80486 we are waiting for your contribution by removing or writing a workflow (github action) automating the removal

[ghost]

Great

[alexbozhenko]

@kazhuravlev, @avelino
so is it a matter of running stale_repositories_test.go automatically?

[avelino]

yep, here

awesome-go/.github/workflows/run-check.yaml

Line 20 in d362ac6

run: go test stale_repositories_test.go

[alexbozhenko]

@avelino it looks like it does not work though: https://github.com/avelino/awesome-go/actions/runs/6917076670/job/18817835071
If I contribute a fix, will you be available to review it?

[avelino]

I look forward to your contribution

[alexbozhenko]

@avelino: could you please review:
#5127

[alexbozhenko]

So if you are actually available to review the code, I think we need to:

• rewrite the test thing using GitHub API golang client, instead of dealing with rest API ourselves.
• Improve the detection criteria. Right now it is simple "no commits for the past year".
• instead of creating an issue with a list, automate the creation of PRs that will actually remove the corresponding line, so maintainers can just merge the PR if they decide that removal is the right thing to do.

[marcusbrown-dot]

Proposal: Operational Pruning of Defunct Dependencies
To maintain the integrity of our digital infrastructure and ensure the security of Kleanslate LLC assets, I am proposing a formal "Pruning Protocol" for our GitHub repositories.

The Rationale:
Allowing defunct frameworks or libraries—specifically those without active contributions or updates for 2+ years—to remain in our codebase creates "Technical Debt." This introduces significant security vulnerabilities, as unmaintained code does not receive critical patches against modern exploits.

The Proposed Step-by-Step Action Plan:

Audit & Identify: Utilize the GitHub Dependency Graph and pip list --outdated to identify libraries that have reached "End of Life" (EOL).
Risk Assessment: Any framework without a commit or release in the last 24 months is classified as "Radioactive." These will be prioritized for immediate removal or replacement with modern, active alternatives (e.g., migrating from stagnant scrapers to Playwright or Requests).

Automated Monitoring: Enable Dependabot across all Kleanslate repositories to automate the detection of security vulnerabilities and version lag in real-time.

Clean-Slate Deployment: Execute a formal "Refactor Sprint" where we remove orphaned imports, update our requirements.txt, and verify that our core business logic—our Void Logic—remains functional without the bloat of dead code.

Conclusion:
A "Klean" codebase is a secure codebase. By removing these defunct dependencies, we reduce our attack surface, improve execution speed, and ensure that our software engineering aligns with the high standards of our physical operations.