I'm developing a application in Python and I've found various packages on pypi which appear to be what I need.

However, how do I know I can trust these lesser known packages - it only has a couple hundred downloads a month? Should I look at the tests/the source code? Perhaps write my own tests for these packages?

Any advise will be appreciated.

  • 2
    Just add them into your program and do some manual testing with common failure scenarios. No matter what you do there will be bugs, no use in killing yourself trying to find every one and talking yourself out of a package you need.
    – user60812
    Commented Oct 14, 2015 at 13:07
  • Just to add one decent indicator is checking issues/bug reports, etc and see how fast the response/fix loop is
    – user60812
    Commented Oct 14, 2015 at 13:08
  • If the project has tests (if not, there's bad sign #1...) you can run them with coverage to get an idea of how thorough the testing is.
    – jonrsharpe
    Commented Oct 21, 2015 at 16:47
  • Check if they have recently accepted contributions. If yes they are likely to take a bugfix if you send them one. Commented Jul 18, 2016 at 8:58

1 Answer 1


I follow this criteria:

  1. Is the package widely used? How many projects that I consider to be large and important are using this package? How often are issues fixed, and commits pushed? Good examples of widely used and actively maintained packages are SQLAlchemy and Django, so I tend to think of them as reference for how well maintained I wish all packages were.
  2. Is the project still actively maintained? How often are there new commits, bug fixes, and issues being closed? There are many packages on PyPI which actually work fine, but they aren't that active.
  3. How thoroughly tested is this package? The more stable it is running on the interpreter you're using, the easier it is to determine how stable it will be in the future, and the easier it will be to fork it and maintain it yourself, if need be.
  4. If there is no viable substitute for a package, and it's not that actively maintained now, I try to speak to the upstream developers. They may have abandoned the package, or it may be that people simply aren't submitting issues. If it has been abandoned, but it may be useful to other people, consider forking it.
  5. Another viable strategy is building a Facade for the package, and writing your code to depend on this Facade, not on the package itself. That way, you could replace implementations in the future.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.