[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
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