Building EXE and MSI installers with AppVeyor?

[peterjc]

I'm wondering if anyone has tried extending the AppVeyor system from just building wheels to also build Windows installers (EXE and MSI fileS)?:

build_script:
    ...
    # build wheel:
    - cd %REPO_DIR%
    - git checkout %BUILD_COMMIT%
    - "%CMD_IN_ENV% python setup.py bdist_wheel"

i.e. Could we add (or being more rigorous, define additional targets for):

    - "%CMD_IN_ENV% python setup.py bdist_wininst"
    - "%CMD_IN_ENV% python setup.py bdist_msi"

I appreciate see that NumPy never went down this route (offering special Windows installers up until https://sourceforge.net/projects/numpy/files/NumPy/1.10.2/ and then only wheels with
https://pypi.python.org/pypi/numpy/1.11.0 onwards).

Do people think that pip is mature enough that we need not worry about Windows installers for Python packages from now on?

[matthew-brett]

Can only offer my opinion, but I gave up writing exe / msi installers for my projects about 2 years ago, and Christoph Gohlke also only supplies wheels these days. The problem with the exe installers is that they don't match the usual Python workflow, and don't work with virtualenvs, so if you're going to provide them, you have to provide a whole extra set of careful install instructions. And yes, pip is now mature, so that I would have no hesitation in offering pip as the default or only install method.

Happy to hear other views though.

[peterjc]

I'd missed that Christoph Gohlke also only supplies wheels now -
http://www.lfd.uci.edu/~gohlke/pythonlibs/

Thanks for your thoughts on this, I think you're right there is now little reason to bother with making Windows installers for the projects I work on.

[peterjc]

Follow some local discussion I accept for some novices, point-and-click Windows installers are sometimes still easier to use than pip at the command line. It might help if python and pip were added to the PATH by default when installing Python on Windows, but they are not.

For reference, the existing appveyor.yml will not test the MSI or EXE packages if generated in place of the wheel - so doing this properly with direct testing of the installers is more work.

However, if you are willing to test manually afterwards, this works to generate multiple packages, test the wheel, then upload all the wheel and exe to RackSpace:

build_script:
    # ...
    - "%CMD_IN_ENV% python setup.py bdist_wininst"
    - "%CMD_IN_ENV% python setup.py bdist_msi"
    - "%CMD_IN_ENV% python setup.py bdist_wheel"

e.g. biopython/biopython-wheels@f759a78 and https://ci.appveyor.com/project/biopython/biopython-wheels/build/1.0.45

Curiously this skips uploading the *.msi files... I'm not sure which part of the stack is rejecting the extension.

[native-api]

appveyor.yml is one of the files that you customize for your project. Since you can add bdist_<whatever> there just fine, I don't see how any changes to multibuild are needed.

Likewise, in deploy_script:, you can add whatever command to upload it wherever you need. If you're having trouble with that command, it's not multibuild-related 'cuz multibuild doesn't have any built-in upload functionality.

[mattip]

Closing. Please reopen and make your case if you feel this is mistaken and you cannot work around it.