Software Discovery

This document describes methods of discovering software on a local operating system.

Copyright, Change Process and Language can be found in RFC1

Change Process

This document is governed by the Consensus-Oriented Specification System (COSS).


Software discovery is the process of finding software by way of key so as to design software for multiple platforms with fluid requirements.

# Absolute path
c:\program files\adobe\photoshop\photoshop.exe

# Key

Discovering software via key is useful in scenarios where it is important to decouple the software you write from the software you interact with.

For example, an application launcher, as defined in Wikipedia is:

..a computer program that helps a user to locate and start other computer programs.

In this situation, absolute paths might look something like this.

c:\program files\maya\maya.exe
c:\program files\adobe\photoshop\photoshop.exe
c:\program files\foundry\nuke\nuke.exe

Which suffers from two immediate problems.

  • PROBLEM1: It isn’t portable to other platforms
  • PROBLEM2: It doesn’t work with custom installation paths

A more portable alternative is the use of keys:


Designing the application launcher towards these keys makes it independent of the underlying platform and where software is ultimately located. The application launcher and references to software have been decoupled from the platform.

The issue then is, how do we resolve a key into an absolute path on the target platform?


  • RFC29 - Persistent Software References


  __________         ___________         __________
 |          |       |           |       |          |
 | relative |------>| resolve() |------>| absolute |
 |__________|       |___________|       |__________|

These are our building blocks. Resolve a relative key into an absolute path. Below are all possible way of achieving this. (Note the use of “all”. Can you think of another way? Hit the edit button)

Blindly Assume

The simplest approach is to not resolve paths and involves assumptions and guesswork.

# Fingers crossed that everyone is running Windows, and
# everyone has their software installed exactly here:
c:\program files\maya\maya.exe
c:\program files\adobe\photoshop\photoshop.exe
c:\program files\foundry\nuke\nuke.exe

This works fine when situation doesn’t change. Where you aren’t concerned with multiple platforms and where all software installations are controlled by you. I.e. we aren’t affected with either PROBLEM1 nor PROBLEM2

Brutal Shotgun Massacre

Extending upon “Blindly Assume”, this is the act of making multiple assumptions about where software may be located.

maya = ['c:\program files\autodesk\maya.exe',
	    'c:\program files\autodesk\maya 2013\maya.exe'

# Run first available path
for guess in maya:
	if os.path.exists(guess):

This method decouples individual installations from the software referencing them and works on multiple platforms by adding additional platform-dependent paths to the list.

As the list grows, accuracy fades. You open up doors to potential mis-fires and an endless maintenance routine as new software finds their way into your domain.

Path generation

The act of compiling a full path via a template.

# Python example
>>> key = 'gimp'
>>> template = r'c:\Program Files\{software}\{software}.exe'
>>> template.format(software=key)
c:\Program Files\gimp\gimp.exe

The template could potentially become shared across workstations and maintained in isolation based on change and requirements.

Path-generation solves PROBLEM1. We can get around PROBLEM2 by ensuring consistent installations on all involved workstation within a facility, but even in these cases, it may become necessary to blend this technique with a small dose of shotgun blast.

maya = ['{platform}\autodesk\maya.exe',

platforms = {'windows': 'c:\program files',
			 'linux': '/opt',
			 'osx': '/home'}

# Run first available path
current_platform = platforms.get(
for guess in maya:
	guess = guess.format(platform=current_platform)
	if os.path.exists(guess):

This and above techniques works for a self-contained facility. But about situations where the location of software is out of your hands? What about situations where you are working together with another facility or a set of remote freelancers?

Centralised Registration

The act of all registering software onto a central location.

available = {'gimp': '/opt/gimp/gimp'
			 'maya': '/opt/autodesk/maya/maya'}

Here, you are no longer dependent of prefixes set by the operating system. Whatever prefix any software installation has is recorded as opposed to guessed.

In a distributed environment, it may even be necessary to register each software to a corresponding workstation.

available = {'workstation1': {'gimp': '/opt/gimp/gimp'
							  'maya': '/opt/autodesk/maya/maya'},
			 'workstation2': {'gimp': 'c:/program files/gimp/gimp.exe',
			   				  'maya': 'c:/program files/autodesk/maya/maya.exe}}

This technique works if your collaborators all adhere to a fluid set of rules and all conform to the same set of keys.

De-centralised Registration

The act of allowing each workstation to fend for themselves.

# Windows
:> set PATH=PATH;c:\Program Files\Gimp
:> gimp

# Linux
$> ln -s /opt/gimp /usr/bin/gimp
$> gimp

Here, gimp is made discoverable by way of making the binary available via the platform’s terminal. The software may then be referenced directly by its executable.

Extended Key

So far, we’ve been referencing software via a key named by the executable.

c:\program files\maya\maya.exe  -->  maya

This is very useful in the Registration example above, but when running multiple versions of software, a key must carry additional information.

c:\program files\maya 2013\maya.exe  --> maya-2013
c:\program files\maya 2014\maya.exe  --> maya-2014