abandon Arduino IDE support

[boneskull]

Hi,

I just came to this project today and have noticed a lot of commits and PRs all centered around one thing:

Getting ino to work with changes made to Arduino IDE 1.x

This is a hamster wheel!

Unless the ino project works closely with the Arduino IDE team to discuss and prepare for breaking changes (across all platforms), some significant percentage of development here will be a never-ending stream of writing no-fun conditionals and accounting for edge cases.

ino pulls all sorts of information from the Arduino configuration files, application folder, and other places. The Arduino IDE isn't an API. You can't count on it to avoid breaking changes.

I don't claim to know all the steps to get there, but here's what I propose:

• Do not read preferences.txt, boards.txt, or whatever
• Do not load packaged libraries, examples, etc
• Do not rely on any sort of path determined by the Arduino IDE
• Do not use compilers packaged with the Arduino IDE

instead

• ino's configuration becomes a directory, probably /etc/ino/ and ${HOME}/.ino
• ino uses whatever's needed from preferences.txt and uses it in its own ini file
• ino distributes its own default boards.txt which can be override in /etc/ino/ or ${HOME}/.ino
• Fork the example code and pull in libraries from wherever they originate
• Do not distribute via PyPi; create .rpms, .debs, and a .pkg installer for Mac (or maybe just a homebrew tap)
• Require 3p, non-Python stuff like avr-gcc and whatever else you need to get the job done

Sure, sure. This is a huge, ridiculous change. But a few more points:

• This doesn't have to happen all at once.
• ino can then move at its own pace instead of have to catch up to each Arduino IDE version.
• ino will be a full-fledged alternative to the Arduino IDE instead of just piggybacking.

Before you call me names, I am a noob to both ino and Arduino--it's likely there's an insurmountable issue here that I'm not accounting for. Or perhaps I'm blowing the issue out of proportion.

However, this is just an idea meant for discussion. I'd like to hear what others think.

[ajford]

I like this suggestion, but haven't taken a look under the hood to see how insane this might be. One thing I suggest against is the abandonment of PyPI. I don't mind having distribution binaries (though I don't think @boneskull realizes how much of a pain managing those binaries are), but as an avid PyPI/PIP user, I need the flexibility to install into a virtual-env.

[scottdarch]

Hello, I'm the new maintainer of a branch of ino called Arturo. Some of your suggestions here are something I may be interested in; namely increasing the functionality of ano (I renamed the command to keep it from conflicting with it's parent project) independent of the Arduino IDE. I don't want to drop Arduino IDE support (which I've fixed in my Arturo fork) but I am thinking about a model where we have community contributed boards.txt and programmers.txt files. Let me know if you are interested in contributing to Arturo.

[boneskull]

@scottdarch I'm not sure I have time to contribute, but I've started using codebender. It might be worth exploring using some of their backend APIs to build a CLI tool.

[scottdarch]

Thanks. I'll take a look.