Get full path to plugin?

Is there a way to get the full path to a plugin after calling `indigo.server.getPlugin(self.pluginId)`?
e.g. /Library/Application Support/Perceptive Automation/Indigo 6/Plugins/My Plugin.indigoPlugin

I could hard-code it, but that seems very error prone and not future-proof.

Code: Select all

    def getIndigoPath(self):
        found=False
        self.indigoVersion = "0"
        for indi in range(5,100):  # we are optimistic for the future of indigo, starting with V5
            if found:
                if os.path.isdir("/Library/Application Support/Perceptive Automation/Indigo "+str(indi)): continue
                else:
                    self.indigoVersion = str(indi-1)
                    break
            else:
                if os.path.isdir("/Library/Application Support/Perceptive Automation/Indigo "+str(indi)): found = True

            def getIndigoPath(self):
        found=False
        self.indigoVersion = "0"
        for indi in range(5,100):  # we are optimistic for the future of indigo, starting with V5
            if found:
                if os.path.isdir("/Library/Application Support/Perceptive Automation/Indigo "+str(indi)): continue
                else:
                    self.indigoVersion = str(indi-1)
                    break
            else:
                if os.path.isdir("/Library/Application Support/Perceptive Automation/Indigo "+str(indi)): found = True

        self.indigoPath   =   "/Library/Application Support/Perceptive Automation/Indigo "+self.indigoVersion+"/"
   =   "/Library/Application Support/Perceptive Automation/Indigo "+self.indigoVersion+"/"


Used in a plugin this will define the variable self.indigoPath as the path to indigo with version. That will work with all indigo api versions. In the newer API versions there is a call to the indigo path, but I cant find it right now.

As your plugin name does not change you can easily hard code that one.

Code: Select all

self.getIndigoPath()
myPluginPath= self.indigoPath+"Plugins/"+"yourpluginName"


Karl

just found it:

Code: Select all

indigo.server.version
indigo.server.getInstallFolderPath()

and this is the Official method to do it.

Karl

Thanks for the pointer, Karl!

I was hoping for something in Indigo that would point to the plugin, just in case they changed the method. This is probably find for now and I will just have to put some extra error checking in just to be sure.

I was hoping for something in Indigo that would point to the plugin, just in case they changed the method. This is probably find for now and I will just have to put some extra error checking in just to be sure.

I have battled this issue as well (the plugin folder being renamed)... I have not checked this, but have been meaning to see if the Plugin Display Name passed into the plugin's init function has the renamed version of the plugin or if it always returns the name defined in the config file. Might be worth a quick investigation as it could be a way to build the full path IF you get the renamed value.

Adam

Good thoughts... I'm not sure if it is possible to end up with a "different" name than the display name. I just tried creating a dummy plugin with the same name but different ID as one I have enabled. It won't install the plugin and instead I get an error: ReloadPlugin() caught exception: FileIOError -- cannot move: destination file exists

So, maybe it is safe to use the install folder, "Plugins" and the display name ".indigoPlugin" for this?

This looks like it is working properly... It does depend on some additional imports (os and plistlib), but they are included in the standard Python distro.

Code: Select all

    def getPluginPath(self):
        self.debugLog('Looking for plugin: %s' % self.pluginId)

        path = os.path.join(indigo.server.getInstallFolderPath(), 'Plugins', self.pluginDisplayName + '.indigoPlugin')
        self.debugLog('Calculated plugin path: %s' % path)

        plistFile = os.path.join(path, 'Contents', 'Info.plist')
        self.debugLog('Plugin info file: %s' % plistFile)

        if (not os.path.isfile(plistFile)):
            self.errorLog('File not found: %s' % plistFile)
            return None

        try:
            plist = plistlib.readPlist(plistFile)
            pluginId = plist.get('CFBundleIdentifier', None)
            self.debugLog('Found plugin: %s' % pluginId)

            if (self.pluginId == pluginId):
                self.debugLog('Verified plugin path: %s' % path)
            else:
                self.errorLog('Incorrect plugin ID in path: %s found, %s expected' % ( pluginId, self.pluginId ))
                path = None

        except Exception as e:
            self.errorLog('Error reading Info.plist: %s' % str(e))
            path = None

        return path


Then, in the plugin's __init__ method:

Code: Select all

self.pluginPath = self.getPluginPath()


[jay (support)]

Out of curiosity, what's the need to know the path to the plugin?

I use it in my plugin to debugLog the full path to a couple of heating schedule files that users can output via an action.


Sent from my iPhone using Tapatalk

I'm considering an automatic update mechanism...

[jay (support)]

I'm considering an automatic update mechanism...

Interesting. Careful though since Indigo moves the actual plugin around as part of enabling/disabling it. I was really hoping to get further down the plugin store/update path for Indigo 7, but I'm not sure if it's going to make it into the first release.

[jay (support)]

I use it in my plugin to debugLog the full path to a couple of heating schedule files that users can output via an action.

So you're dynamically writing these files out and the user will get them and do something with them? I would highly recommend you not write into the plugin in that case. Python can create a path starting with a tilde (~ - that represents the user's home directory) though at the moment I don't remember how to get it to expand - but that would seem like a better alternative. The other option is to write the file into the system temp directory but I don't recall how to do that at the moment either. Both would be better I think given that you'd be writing into directories that are meant for public consumption.

[jay (support)]

To expand a user's path:

Code: Select all

import os
os.path.expanduser("~")

That returns something like:

Code: Select all

/Users/jay

or whatever the logged in user's home directory name is. Use that as the path and you're pretty much guaranteed to be able to write there (unless there are some seriously messed up permissions). Then the user can just look in their home directory for the file.

You could also create a temp file, though the path to temp directories is also somewhat obscure.

[matt (support)]

I'm considering an automatic update mechanism...

Interesting. Careful though since Indigo moves the actual plugin around as part of enabling/disabling it. I was really hoping to get further down the plugin store/update path for Indigo 7, but I'm not sure if it's going to make it into the first release.

One interesting thing to note on updating plugins is that the Indigo Server has a built-in plugin version resolver, so if multiple copies of a plugin are found in either the enabled or disabled folders it will resolve them appropriately. We use this internally in conjunction with our installer.

The way the resolver works is it looks in both the enabled AND disabled plugin folder for duplicates. If it finds any, then it moves all the older versions to the trash (the newest version always "wins"). Additionally, if there is a plugin in the enabled folder then the winning plugin, no matter where it is (even in disabled folder) will be moved to the enabled folder. This keeps the plugin enable/disable state correct.

The way Indigo's installer uses this is that it always places new versions of plugins in the disabled plugins folder. On the next server launch, the plugin resolver will then handle the case where the older plugin, which needs to be replaced, is in the enabled folder. In that case the older copy in the enabled folder is moved to the trash and the newer version is moved over from the disabled plugin folder to the enabled plugin folder.

Purely an FYI... it might not make sense to use that with a plugin updater since it only runs (currently) when the Indigo Server launches, thus it requires an Indigo restart.

That is pretty interesting, actually... It makes concerns around multiple versions go away.

My plan (hope) is to extract the plugin in-place to where it is currently loaded and simply restart the plugin. I'm attempting this as part of my GitHub Updater. We'll see what I can break by doing that and report back