Plugin tutorials?

Hi all,
As I prepare to take the plunge, I have been searching for something resembling a tutorial on how to start. I have read the documentation and taken notes, though I am having trouble assessing where I actually start! As far as testing- if pycharm and an Indigo debugger is the way to go, I’ll learn that earlier than later. At present, all of my scripts are tested in Indigo action groups with liberal log entries.

Training wheels needed. I know how to pick up new languages and code (at least, without an IDE), but this is a new endeavor. Thanks in advance


Sent from my iPhone using Tapatalk

The single best place to start, IMHO, is the example plugin folder listed under your Indigo installation - there are about a dozen different sample plugins for you to toy around with. That is what they are there for, tutorials. It gets your feet wet and you can start coding real plugins immediately. Next I would take a gander at other peoples plugins and see how they did something you find interesting. I assume, in all of this, you have read over the Indigo plugin SDK docs too.

in all of this, you have read over the Indigo plugin SDK docs too.

Thanks C4W, I have printed out and read through/ taken notes on the SDK- it’s well documented and the theory makes sense... it’s the practical I am trying to think about. Some example questions I have:
1. Should I just edit an example plugin and load it up?
2. Any problems removing plugins that I screw up?
3. Should I get an extra copy of Indigo and run it in a VM? Clone my installation (or drive) before tinkering? Basically, how do I avoid screwing my current installation?
4. Use TextWrangler or jump to pycharm now?
5. Debugging recs?

I spend most of my HA time with a pencil and paper on a train, with limited time in front of a machine. This works as I can develop a systematic approach prior to hacking my way through code. Downside- I really have to maximize my time spent in front of a computer.

The plugin contributors here (you, Dave, Karl, Perry, Nathan, Rogue, autolog, FlyingDiver, Roussel, Durosity (sorta ;P) and sorry any I am forgetting) are my spirit animals. I just need a vector to run in and simple thoughts are very appreciated.


Sent from my iPhone using Tapatalk

Take a look at the Plugin Developer Documenter Plugin - an excellent piece of documentation from @RogueProeliator.

Pycharm is excellent for Indigo debugging as you can single step through your code, it highlights code errors as you code and helps you to write to standards.

I tend to use Sublime Text as my main editor and then switch to Pycharm for testing and double checking the code.

1. Should I just edit an example plugin and load it up?
2. Any problems removing plugins that I screw up?
3. Should I get an extra copy of Indigo and run it in a VM? Clone my installation (or drive) before tinkering? Basically, how do I avoid screwing my current installation?
4. Use TextWrangler or jump to pycharm now?
5. Debugging recs?

1. None, if you use the example then rename the file, change the name in the info.plist and copy it to your plugins and restart the Indigo server (or double-click to install it)
2. None, you can disable or delete the plugin package file as needed
3. No need really, some of us do use a development copy if we have fairly complex plugins just so we can isolate it and test what the experience would be for an end user who doesn't have all the 'stuff' we have loaded, but otherwise you really don't need it
4. Personally I love TextWrangler and do all my coding in there but PyCharm is good too, personal preference
5. I'm not sure what you mean by this, but you do your own debugging mostly (unless you use PyCharm or similar debugger)

I would recommend reading up on Python too. Knowing what the standards are can be very helpful. For example, I ignored putting headers in my files for the longest time (__modname__ and __version__, etc) and now I do it religiously because I found it easier in a number of ways. Knowing syntax such as 'if x not in y' is recommended but not 'if not x in y' make debugging your code easier and make it more readable to others.

Take a look at the Plugin Developer Documenter Plugin - an excellent piece of documentation from @RogueProeliator.

How did I never even notice this- looks to be super helpful hands on learning.

None, if you use the example then rename the file, change the name in the info.plist and copy it to your plugins and restart the Indigo server (or double-click to install it)
None, you can disable or delete the plugin package file as needed
No need really, some of us do use a development copy if we have fairly complex plugins just so we can isolate it and test what the experience would be for an end user who doesn't have all the 'stuff' we have loaded, but otherwise you really don't need it
Personally I love TextWrangler and do all my coding in there but PyCharm is good too, personal preference
I'm not sure what you mean by this, but you do your own debugging mostly (unless you use PyCharm or similar debugger)

Exactly the kind of advice I was looking for, thank you again.

Take a look at the Plugin Developer Documenter Plugin - an excellent piece of documentation from @RogueProeliator.

I plan to update that - it is missing a couple of the latest plugin features (though most of these are more "advanced" things). Maybe your recommendation will inspire me to get off my butt and do the update

Durosity (sorta ;P)

I beg your pardon?!?!

Word of advice: Durosity’s job here on the forums is to derail any thread on Jays behalf so Jay can avoid having to answer it. In exchange, Jay allows Durosity to share half his house and the private plane.

Never take any coding advice from Durosity; it’s likely to break something.


Sent from my iPhone using Tapatalk Pro

[jay (support)]

It's perfectly acceptable (and encouraged) to start with one of the example plugins in the SDK as the base for your plugin. Just pick the one that does the kind(s) of devices your plugin will support. Don't forget to change the ID in the Info.plist - you'll probably want to do that first thing so that you don't have to do a migration later. Plugin ID's should never start with com.indigo* or com.perceptive*.

If I were just starting, I think I'd probably just use a text editor to begin with. You can set breakpoints and use pdb or PuDB if you want to debug at first (both are included with Indigo). PyCharm, while thoroughly awesome, has a bit of a learning curve, so when you factor in being new to Python and being new to the Indigo IOM/SDK, it might be a bit overwhelming. But maybe not - it'll just depend on what you're used to.

Knowing syntax such as 'if x not in y' is not recommended but rather 'if not x in y' make debugging your code easier and make it more readable to others.

Oh, wow - really? I always write it x not in y because I think it's easier to read. I wonder if I should change...

[EDIT]OK, so the worrier in me had to make sure that I wasn't doing a bad thing™. I did a quick search which seems to indicate that they both compile to the same bytecode so either would be acceptable. Whew, I really didn't want to go change them all!

Oh, wow - really? I always write it x not in y because I think it's easier to read. I wonder if I should change...

[EDIT]OK, so the worrier in me had to make sure that I wasn't doing a bad thing™. I did a quick search which seems to indicate that they both compile to the same bytecode so either would be acceptable. Whew, I really didn't want to go change them all!

It's only a readability thing. According to the guidelines written by the guy who invented Python, his take is that it's easier to read 'if not x in y' rather than 'if x not in y' but it makes no difference as far as how it works.

According to Pep 8 it should be 'if foo is not...' rather than 'if not foo is' I wrote it backwards actually, I meant to say it the other way around . I didn't notice that when I posted, I fixed my post .

Then there is also Pep 257 that talks about using docstrings in your code.

[jay (support)]

I wrote it backwards actually, I meant to say it the other way around . I didn't notice that when I posted, I fixed my post .

Ahhh, that explains it!