Usage Statistics

[mottosso]

Goal

Know which part of the API is used and how much, in order to simplify refactoring and guard against modifying heavily used functionality.

Motivation

As Pyblish grows, it also accumulates a lot of functionality. Some things you are unlikely to have ever heard of, things I could modify or remove without anyone knowing, and thus reduce the things that needs support and maintenance, simplifying the overall library.

Or can I?

Usage statistics take the form of counting calls to exposed functionality, such as the amount of times a function is called or a class instantiated.

{
  "pyblish.api.Context()": 53,
  "pyblish.api.register_plugin()": 6,
  "pyblish.api.sort": 0
}

The collected information is then either stored locally, or transmitted to a public repository where this information can be inspected.

What about privacy?

Statistics will always be stored locally to begin with. Whether it is then implicitly or explicitly sent to the outside worlds is still something we'll have to think carefully about. In most cases, these integers will be of little harm, but it's important to facilitate those who need absolute privacy and protection.

When statistics remain local, a user will have to explicitly hand over the statistics to an interested party, such as Abstract Factory. Possibly under the guise of a contract or other protection device.

The goal is to gain insight into what can easily be changed and what needs special care and attention to maintain for backwards compatibility. Ideally, the data would always be sent, with an option to "opt out".

Implementation

Attributes exposed via pyblish.api are given a special counter, the collected data is then automatically written to disk at even intervals or interpreter shutdown. Any I/O is done in a separate thread to eliminate noticeable performance hits.

[tokejepsen]

+1

Would the usage statistics be used for internal as well? Like being able to see how often a plugin is being used?

[mottosso]

It's a little bit of a different use case, with different sensitivity on the kind of information going out.

For internal use, you could simply attach a counter yourself and store the results however. For example, you could override pyblish.plugin.process, the function responsible for all processing.

import pyblish.plugin

counter = 0

def my_process(*args, **kwargs):
  counter += 1
  return pyblish.plugin._process(*args, **kwargs)

# Store reference to original
pyblish.plugin._process = pyblish.plugin.process

# Override original
pyblish.plugin.process = my_process

Let's have a chat in the forums about specifics if this is what you're interested in. There are many ways to skin a cat. And also, it could be interesting as a feature of its own.