DevOps

1691 readers

1 users here now

DevOps integrates and automates the work of software development (Dev) and IT operations (Ops) as a means for improving and shortening the systems development life cycle.

Rules:

Posts must be relevant to DevOps
No NSFW content
No hate speech, bigotry, etc
Try to keep discussions on topic
No spam of tools/companies/advertisements
It’s OK to post your own stuff part of the time, but the primary use of the community should not be promotional content.

Icon base by Lorc under CC BY 3.0 with modifications to add a gradient

founded 1 year ago

MODERATORS

Ategon

RandomDevOpsDude

[N]ew deadcode Python package for detecting globally unused Python code (pypi.org)

submitted 1 year ago* (last edited 1 year ago) by jnovinger to c/devops

1 comments fedilink hide all child comments

cross-posted from: https://programming.dev/post/196935

To be clear, this isn't my project. Just cross-posting the author's post from [email protected] .

Sometimes unused class or function manages to slip into code base. Static code checkers like ruff, flake8 does not have rules for detecting such globally unused code.

I tried using vulture, but it has too many false positives to have it as part of CI/CD pipeline.

I have tried to implement my own, more reliable check for global deadcode detection.

Please let me know what you think about it.

you are viewing a single comment's thread
view the rest of the comments

[–] RandomDevOpsDude 1 points 1 year ago* (last edited 1 year ago)

This is an interesting option and probably pretty useful for python projects.

Although I generally push back against use of python usage as a build tool (it is not a build tool), I know tons of people still use python scripts in their CI (as a build tool), which, I think only makes sense if you are a python shop. Why install python to build java, for example? (pro-tip - don't)

Disclaimer: these opinions are mainly targeted toward closed source enterprise software.

People love using all sorts of fancy stuff in their CI, and I am personally a CI purist. If it can be done in bash, do it in bash. See scripts-to-rule-them-all by GitHub, which I personally think is still too little, but at least sets a good foundation.

CI purist examples:

I am of the opinion that if one feels like they need credentials for their cloud provider in CI (besides cloud provider as artifact host), the project probably needs better unit testing rather than integration tests requiring all sorts of real creds to be injected. Does it take some extra time, sure, but arguing against push back for "better testing" is not an easy path to go, trust me. ("No!!! My couple integration tests with bunches of dependencies injected are easy and get a lot of code coverage!!" -- code coverage != good tests)

I am also of the opinion that one shouldn't even be using things like 3rd party GitHub actions that one has no idea what they actually do, just that it works, and then auto bring in updates that one doesn't actually watch what is being updated. Sure it still works, but did it turn into malware, the project auto pulled in updates, and no one was watching? How does one know, if one isn't watching the upstream changes.

CI/CD is primetime for supply chain attacks. It is not an if, but a when. Prepare for the inevitable.