I've noticed this kind of thing with lots of Google products actually - they're often written for downright ancient versions of python and can be a nightmare to get working with modern pythons. Any clue as why this is?
That's not complicated for Windows dev. Windows devs are used to a bunch of configuration, because they grew up with it. Besides, those steps are easy to follow, and can be done quickly.
Setting environment variables is as easy as writing a .cmd file that sets them for you.
Most devs have Python installed.
Installing Scons is easy.
A paid version of VS can be easily pirated if you don't feel like paying for it. This isn't by accident: MS would rather you be writing Windows software than non-Windows software. And if you're writing software to sell, then a license isn't costly: https://www.google.com/shopping/product/7152061321388788226
I understand what you're saying, but it simply is not an excuse.
The whole point of this tool is to make installing and updating packages easier, but at the same time they have one of the most complicated installation instructions for a standalone software package ever. That is something that makes me wonder how much they really care about simplifying the workflow of installing and updating packages.
Hm. There's a Stack Overflow link elsewhere in the thread... In it, someone reported they were able to set up Omaha and have it continue to work for over a year without needing to touch it once. That's pretty solid. http://stackoverflow.com/questions/3711435/what-is-the-exper...
Are you sure a day or two of work in exchange for over a year of solid deployment isn't a good exchange? If it isn't, then which alternative would you recommend in order to get similar efficiency?
Not sure who downvoted your GGP comment, you did have a valid point.
Nonetheless, I think there's hardly ever a justification for asking other people to perform "a day or two" of work to set up something, even in exchange for years of solid deployment. A day or two, multiplied by thousands of Windows developers, adds up to several man-years of entirely avoidable work.
Entirely avoidable, because it's Google's job, not ours, to package up this Omaha thingy into a neat binary with a neat API that any project can easily use. It's not too difficult to ship a single binary (or collection of binaries) that will work out of the box on every Windows Vista/7/8 PC, with the only dependencies being the Win32 API, vcredist, and perhaps a recent version of .NET Framework. Wrap it all up in an .msi and you're good to go. No need to tell a C# developer, for example, to meddle with Visual C++ or Python.
If the Omaha devs can spend a few weeks to make the setup process as simple as that, now that would have a real chance of adoption.
It's easier than rolling your own, which is what most Windows developers do. It's strange that Windows still doesn't provide this for desktop applications.
Also, VS pro is something that a Windows developer could already have. I do not agree to pirating it, though - but MS do provide it for free/cheap if you jump through a few hoops.
"Now, a year later, do you have any updates to share regarding your experience with Omaha?"
"The update system is still running well with no required maintenance for the past year. The server gets almost a request a second at peak times... Omaha checks for updates every 5 hours. If the version that the client has doesn't match what is published it sends a URL (hosted by Rackspace) of the updater. Omaha downloads, verifies, and runs the updater."
So, there's an upfront initial time investment to get it running, and then you don't have to touch it and it still works a year later.
God we went down a rabbit hole trying to get omaha working last year. It is seriously complex. It's much-needed though, as Windows Installers are perhaps the most fucked things in existence. I am perhaps more excited for Github's Squirrel (was Shimmer), which has an awesome team behind it and notes simplicity as a priority.
I just looked into this, but it was ridiculously complex.
I just went for a Wix installer instead that installed cygwin cron as a service. The cron job then rsyncs the current version into the install dir every 5 hours. Finito.
Looks pretty cool, especially autoupdate. I'm going to take a closer look at this. AFAIK, MS has dropped support for installshield LE in VS 2013 leaving developers with the choice of buying installshield, using NSIS, or cobbling together something with ORCA, if that is even possible. Deployment is definitely the biggest pain point in windows development.
It's pretty slow at checking for new versions, though. I get the impression that's because of the way they seem to scan your disk (it seems to be a brute force "scan every directory on the disk looking for .exe files"). Also, it's fairly common for it to flag your version as out of date and then be unable to automatically update it (although it provides you a handy link to either fetch the setup your self).
That said, it's handy to have a centralised point to check for updates.
Just in order to use Omaha, you need:
- A non-Express (i.e. paid) version of Visual Studio
- Python
- Scons
- Set a bunch of environment variables, because who needs configuration files?