Windows installer... again.

[RoDuth]

Is this any better for you? Its fairly self explanatory.

I've tried to make it as simple and repeatable as possible. All the versions of the NSIS plugins I used when writing the script are now in situ so you no longer have to install them. If you do a full install of NSIS v3 (or even a minimal + plugins and user interfaces) all other dependencies will be satisfied.

I used VirtualBox and the Windows VM images to test all of this. Its handy to be able to take a snapshot while the machine is running so you don't need to reboot it and can just power the VM off when your done. You can then return to the same place to pull the latest changes and rerun scripts\build_win to create a new release. I've used it on a Win7-10 but would recommend Win7 as being a little faster to work with in a VM with the same outcome.

I've included doc/build_win.rst which should explain everything in a little more detail. I'm not sure if this documentation does fit in build.rst but am happy to plug it on the end if it is where you think it belongs (I see you have a place holder there). The note "about the installer" would probably reside better on the releases page.

python setup.py nsis does allow specifying a different script or install location for makensis if you ever needed it but the defaults will work fine with the current script and any default install of NSIS 3.

Another approach I tried but haven't included in the documentation is to set your ghini repo (or a copy of it) on the host machine as a shared folder so you can do all the git actions on the host and have no need to install it on the VM. Then download the pyGTK, Python and NSIS installers on the host and place them in a shared folder also. When you fire up the VM install the dependencies from this shared folder, open a command prompt and using something like E: cd ghini.desktop change to the repo then run scripts\build.bat from there (taking a snapshot at that point). This way you don't need to enable a network adaptor, producing further installers becomes quite trivial (fire up the VM with the command prompt in place, run the script and power off) and the installer and dist folder are available to the host machine without any need to manually copy anything.

[coveralls]

Coverage remained the same at 66.493% when pulling 62b436f on RoDuth:ghini-1.0-wininstaller into e63f42f on Ghini:ghini-1.0-dev.

[coveralls]

Coverage remained the same at 66.493% when pulling b19f282 on RoDuth:ghini-1.0-wininstaller into e63f42f on Ghini:ghini-1.0-dev.

[mfrasca]

docs don't mention activating the virtual environment. and if I do activate the correct virtual environment, build_win says none was active and insists in creating a new one anyway.
I'm afraid that your script doesn't recognize the path if it contains spaces, like mine does (\Users\Mario Frasca\)

[mfrasca]

I didn't test any further, I just stopped after the first two errors.

I also consider and suggest the following:

• you don't produce an installer on a clean system.
• on my machine I keep several virtual environments and work with several checkouts.
• you want to use whatever checkout and whatever virtual environment you choose.
• I suggest that the script stops if no virtual environment is active.

I rather leave this completely to you. thanks.

[coveralls]

Coverage remained the same at 66.493% when pulling 23aa20c on RoDuth:ghini-1.0-wininstaller into e63f42f on Ghini:ghini-1.0-dev.

[mfrasca]

there surely is a reason why you prefer creating a new virtual environment (and hard code the name).
what is it?

[mfrasca]

please consider this (untested):

diff --git a/scripts/build_win.bat b/scripts/build_win.bat
index 25cb3b04..71dc8c94 100644
--- a/scripts/build_win.bat
+++ b/scripts/build_win.bat
@@ -1,24 +1,16 @@
 @echo off
 
-IF NOT EXIST "%HOMEDRIVE%%HOMEPATH%"\.virtualenvs\ghi2exe\Scripts\activate.bat (
-  ECHO creating an isolated virtual environment to build in
-  pip install virtualenv
-  virtualenv --system-site-packages "%HOMEDRIVE%%HOMEPATH%"\.virtualenvs\ghi2exe
-)
-
 IF "%VIRTUAL_ENV%"=="" (
-  ECHO Activating virtual environment to build in.
-  call "%HOMEDRIVE%%HOMEPATH%"\.virtualenvs\ghi2exe\Scripts\activate.bat
+  ECHO "please select a virtual environment first."
+  EXIT 1
 ) else (
-  ECHO Currently using virtual environment: "%VIRTUAL_ENV%"
-  IF NOT "%VIRTUAL_ENV%"=="%HOMEDRIVE%%HOMEPATH%\.virtualenvs\ghi2exe" (
-    ECHO deactivating previous virtual environment and activating one to build in
-    deactivate
-    call "%HOMEDRIVE%%HOMEPATH%"\.virtualenvs\ghi2exe\Scripts\activate.bat
-  )
+  ECHO Using virtual environment: "%VIRTUAL_ENV%"
 )
 
-ECHO Installing dependancies
+REM you here need a test whether all of the following can be installed in a
+Rem virtual environment, or if the user/developer is forgetting something.
+
+ECHO Installing dependencies
 pip install py2exe_py2
 pip install psycopg2
 pip install Pygments

I did not read the rest yet.

[mfrasca]

a note to myself, I'm sure you @RoDuth are already familiar with the page.

[mfrasca]

I think this is still incomplete. there are issues with installing py2exe_py2 (like needing a C compiler? I don't remember, I only know that pip install py2exe_py2 puts a py2exe which will not find the installed modules, starting at gdata). anyhow, you do not mention any of this in the instructions.

[RoDuth]

@mfrasca Sorry, life got in the way for a little while... and I still don't really have time right now but if you do still want me to (I keep getting the feeling that for some reason you don't want a windows installer at all?) I can finish this, I just need some time and to understand what it is that you want.

It really is very simple, you just need to do these steps:

1. Download and install Python 2.7, PyGTK and NSIS v3.

2. download the ghini source however you like

3. fire up a python 2.7 virtual environment and pip install py2exe_py2 psycopg2 Pygments.

4. from the root of the ghini source pip install . (instead of the usual python setup.py install because py2exe doesn't work with eggs. If you use pip to install then you don't need to worry about a compiler or any of the other issues you may run into. This is the reason for using a fresh virtual environment. They are cheap after all).

5. python setup.py py2exe nsis.

The ghini.exe in the dist folder will work where it is but if you wish to move it (i.e. put it on a usb stick) you'll need to register the gtk paths again with the 3 commands in the win_gtk.bat file.

build_win.bat was just something I wrote to make life easier but its not required. (same as devinstall.bat it won't work on systems such as mine where I have python 3 as the default and the "python launcher for windows" unless you are already in a python 2 environment.) I find it handy in the method I described where I have a win7 VM and share my ghini folder, with a command line open at the source root directory in the windows machine saved as a snap shot. That way I can do everything but test the process works in linux and just fire up the VM at the snap shot, run build_win.bat to see if its all working and close it (no shutting down, booting or rebooting). Almost as fast as opening a browser window! I would rather drop build_win.bat altogether and just state the 5 steps required.

[RoDuth]

Also, other approaches I've seen to the eggs issue are to either unzip the packages in situ, which seems like an ugly hack to me, or to add

[easy_install]
zip_ok = False

to setup.cfg (or similarly zip_safe = False in setup.py) but this would affect all installs and still requires a fresh virtual environment anyway. From memory, this is also when you may need a compiler, to get the c extensions for some of the packages. To me using a separate virtual environment and pip solves all these problem without affecting anything else. You could use pip install -U but again I'd rather not affect the usual working environment (I haven't even tried this so can't verify it works).

[mfrasca]

for some reason you don't want a windows installer at all

I don't need a Windows installer, that's quite correct. But I can accept one I can update myself with the least effort. I'm a very forgetful person, so I'm used to writing everything down. this practice is the base for our documentation. I need all steps written down, I need to be able to follow them and to be sure that future developers can follow them too.

if you can write your instructions considering the developer ALREADY has everything in place for running ghini. This will reduce the length of your writing, and the chance that the reader will think "oh, that I already did", missing one step you're hiding among well known steps.

as said: I don't want a new virtual environment if not strictly necessary.

so: whenever you have the time, please review the documentation. I will try it again when you're done. if I can follow the steps you describe, I'll be happy to include your contribution to software and documentation.