Windows Installers

[Colin Newell]

Hi,

I've been starting to roll windows installers and one of the things I
realised is that it would be handy to have a repository for the binary
dependencies. The MySQL installer and all the other Python libraries
that we bundle in the big installer that contains all the
dependencies.

Source code repositories generally aren't ideal places to store large
binary files so we definitely shouldn't add it to the main code
repository. I was thinking it might be worth creating a secondary
repository somewhere for these files. That way we can have them
somewhere available to anyone needing to build an installer, and it's
easy to see and manage what gets bundled with the installers.

Creating a repository with these as mentioned is ugly at best however.
One of the downsides is that it is likely to consumer a lot of disk
space. Another is that it will contain a bunch of third party
binaries that are available at other places on the internet. In the
past with commercial projects I've simply lived with that because of
the convenience. It also allows for greater stability.

Does anyone have any better suggestions for managing our installer dependencies?


Colin.

[Colin Newell]

Hi,

I have scripted the installer build process and updated the
documentation to explain how to do it. I hope that by scripting it it
should become easier for developers to roll a new installer. Right
now this is in the sqlalchemy branch, but I intend to merge to the
default branch sometime soon.

https://code.google.com/p/open-ihm/wiki/CreatingOpenIHMWindowsInstaller

There are still quite a few improvements I'd like to make, but for now
this should be a start. One of the things I've done is push all the
external dependencies into a repo as I suggested previously to make it
simpler to get going initially. It should also allow us to ensure
everyone has a more consistent set of dependencies with future
installers. We can always upgrade our dependencies, but we should
only need to do it when there is a compelling reason to do so, rather
than simply because somebody is started work on a new development
machine.


Colin.

[Sarah Mount]

Just to echo what Colin has said here, this is very useful work which overcomes a number of tricky problems. In particular we now have one place where the "version" of the current open-ihm install is defined /and/ we are able to track (from the dependencies repo) what has been installed alongside each version of open-ihm. This will make dealing with bug reports from users considerably easier.

When Colin has merged this work into the default branch it will become possible to generate new installers for "releases" of open-ihm. It will also become possible to work on a "test" version of the Windows install that does not touch the database of real project data that EfD staff will have on their machines. 

So, until this work appears in default there should be no more "releases" of open-ihm, and when it is merged into default anyone wanting to create a release should start a discussion here about how we can test release candidates before they get out to users. Hopefully then we can work out a process that everyone can stick to and minimise the number of problems that real users can see.

Cheers,

Sarah

--
You received this message because you are subscribed to the Google Groups "openihm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openihm-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Sarah Mount, Senior Lecturer, University of Wolverhampton
website:  http://www.snim2.org/
twitter: @snim2