distributing windows installer

[RoDuth]

see #109, #126, #286

Now we have an installer for windows, once we have settled on a distribution location, we can make ghini check for new versions of the installer and notify the user. For now ghini doesn't check at all when its installed this way.

[mfrasca]

I guess there's not that much to choose from, here on github: the natural place for releases is in the releases tab. an hypothetical binary installer for ghini.desktop-1.0.75 would possibly go here: https://github.com/Ghini/ghini.desktop/archive/ghini.desktop-installer-V1.0.75.exe.

imagine I release an installer for 1.0.75 today. and next year one for 1.0.98. right. no windows binary in between, because I'm lazy and because it's an heavy extra step. 1.0.75 would notice that history is proceeding, but no release is in place. this makes the test a bit more complex, and also what we have to tell to the user.

please note: you have an installer for Windows, not we 😬 : I still didn't manage to produce one and we still have no documentation about how to do it: grep -rn py2exe doc gives no result. I would expect a small paragraph somewhere in doc/building.rst.

[mfrasca]

@RoDuth, would you send me the newest installer you managed to produce? as said, I can't yet replicate what you describe in pull request #297 (reason why I'm not merging it), but we can at least start distributing what you have.
A quite obvious place for it could be next to ghini.pocket.apk.

[RoDuth]

The latest version I have built is available here but this is built on the MRBG branch (only differing by the one commit which allows provisional names) and its from a few patch releases ago. Would be easy enough to produce an installer for ghini-1.0 ...except that all the code now sits in a dev branch so you'll get unreleased commits if I build it from that the wininstaller branch. If we can get a version your happy to merge in I'm happy to build it.

The only thing I can see that could be causing you issues is the eggs that py2exe wont work with. If you really want too you can even reinstall non-egg versions over the top of the packages in you current installs virtual environment using pip install -I . (warning- I know this will work but have no idea if this affects the usual install, not sure why you would wont both though). So, using that approach and your current virtual environment, the whole process from an installed copy shouldn't involve anything more than installing NSIS v3 then pip install py2exe_py2 psycopg2 Pygments lxml (if you haven't already installed any of these) -> pip install -I . -> python setup.py py2exe nsis . What have you tried? So I can try to understand what isn't working for you. It works for me across quite a few different installs without any issue.

[mfrasca]

Please whenever you have the time, review your instructions, those you are asking me to accept in the ghini-1.0-dev branch, so that I can follow them and test them again. don't, please, add so many side paths that I can test: I can't test them, my access to Windows machines is very limited. the current version of your documentation is incomplete, that's why it's still on hold.

as I wrote, I started following your instructions and they failed, you have fixed the "spaces" issue, but the script still creates a new virtual environment when one is already in place.

if I need to install py2exe_py2, please describe it, and describe how I should install it. I have installed it (in the most obvious way, I think it was just pip install, but I don't remember), but it doesn't work (it won't locate any modules I have in the virtual environment, starting at gdata). I haven't found a working way to install py2exe_py2, this is why I haven't written down how to do that.

Thanks for the executable installer though. at least I can handle that to very lazy windows users.

[RoDuth]

It is just pip install py2exe_py2 (which build_win.bat will take care of for you if you wish to use it) and, as I have been saying, py2exe wont find modules when you have installed them using python setup.py install because they are installed as eggs. This is why I chose to use pip install and a different virtual environment to devinstall.bat. The way I see it is that it would be more usual for someone to only have one or the other environment, not both, dependent on their preferred install method. This is why I made build_win.bat not depend on devinstall.bat nor care or interfere with its environment if you have used it. If you wish to ignore build_win.bat and already have the environment created by devinstall.bat you can try the method I described in my last post, it worked for me.

There are so many variations on how to go about this, the main point is you can't use eggs. I see little point in documenting all variations in detail. The way I see it some general guidance is all that is needed with build_win.bat given as an example of how to achieve it. I will try to find some time in the coming days to add it to the documents.

[mfrasca]

I see, "eggs". while on my site the point is that I'm not working with only one environment, but with as many environments as development branches, and I'd rather decide the name of the environment, not leaving it to a script. this happens for the end user and I find it acceptable in that case. but for a developer, no, I'm sure developers want to keep this in their hands (this is my case).

I see little point in documenting all variations in detail

there's no need to describe "all variations" if you describe the reason behind the rules.

[RoDuth]

I guess I had been working off the approach that a developer is likely to check what a script does before running it. (I certainly do and I'm not a developer).

I am coming from the use case I have: system administrators in a large government department needing a deployment method across a large network where the software may be needed in more than one depot with large physical distances between the system administrators and the depots that require the software. If there isn't an installer available then the software simply can't be used. So, in the future if there isn't anyone to produce it for them, then lets make it as easy as possible for them to produce one themselves (download a few things and run a script and they'll have an installer they can transfer to the network to deploy with.). Its also the reason I added the silent install options to the installer. To make it as easy as possible for them to roll out at night when they normally deploy desktop software.

[mfrasca]

I'm closing, seeing this as a duplicate of #109
feel free to reopen if you think this is a different issue.