[python-uk] Reviewing third-party packages

Steve - Gadget Barnes gadgetsteve at hotmail.com
Sat Jul 29 00:40:53 EDT 2017

On 28/07/2017 10:08, Patrick Morris wrote:
> On 28/07/2017 05:54, Steve - Gadget Barnes wrote:
>> On 28/07/2017 00:27, PyUK at getaroundtoit.co.uk wrote:
>>> S, (Andy and Mike)
>>> Yes, you've hit a couple of pertinent points; and it might make for an
>>> interesting project.
>>> However, I was looking for a check-list or similar which I can give to
>>> the pertinent dev.teams to ensure that they are 'covering all the bases'
>>> - whereas the question: "have you checked 'everything'?" produces a
>>> rather predictable response.
>>> I'm thinking someone wiser than I will have written these things down -
>>> just can't find such...
>> As a starting point, my personal mini-checklist, for considering
>> including packages:
>> 1. Licensing: Is the project only ever going to be internal? If there is
>> any chance of it's being included in a commercial deliverable then the
>> licence and all of it's dependencies must be "Apache or better" and have
>> a chart of the acceptable permissive licences vs. usage. Basically the
>> licences that we generally have green flags for are MIT, BSD, CC-BY,
>> MMS-PL & PSF. With some yellow flags on Artistic/Perl & Apache.
>> 2. A quick look at the project repository for indications of activity
>> such as recent check-ins, outstanding tickets, age of pull requests,
>> discussion levels & tone on tickets. (Call this an abandonware check).
>> 3. The reputation, on-line & off, of the authors & maintainers.
>> 4. Is it hosted on a host that hasn't announced its own demise.
>> 5. Test coverage &/or Coverity
>> 6. Do the requirements look reasonable for the nature of the package,
>> e.g. I wouldn't expect network or server type dependencies in a screen
>> shot package.
>> 7. Ditto the imports
>> 8. If there are none-Python elements are they about what I would expect,
>> i.e. things that you would expect performance issues with?
>> 9. Support for Python 3 & 2 or at least a clear statement.
> All of the above are good
> You could also use the following to check for known vulnerabilities
> https://www.openhub.net/explore/projects
> Patrick

Excellent point to add to the above along with:
What does a pylint run look like? Not so much the naming constraints but 
the general code quality metrics - of course if the source of a library 
gives a completely clean pylint result it starts off with a lot of 
brownie points in my book.

Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect 
those of my employer.

This email has been checked for viruses by AVG.

More information about the python-uk mailing list