Offer as chocolatey package

[koppor]

As user, I would like to run following command to have a2 installed

choco install a2

It would be nice if this was possible. Details on chocolatey packaging can be found at https://chocolatey.org/docs/create-packages. To ensure longer support of chocolatey package, I would suggest that someone closely related to a2 creates a package. Otherweise, it could become unmaintained.

[ewerybody]

Hello @koppor, yeah we were looking into this a while ago. I'm not super involved in chocolatey yet. So it became silent around this.
But its nice to see that there is interest. So yeah. We can do this!

[OlafHaag]

I could create the choco packages. However, for this to work I'd need to know the silent switch of the installer.
Universal Silent Switch Finder (1.5.0.0) gave me:

USSF detected that the file you selected is a valid PE file.
However, it couldn't identify its type.
The header returned by PEiD was 'Microsoft Visual C++ 6.0 [Overlay]'

And neither of /q or /silent worked.

[ewerybody]

Oh. I don't think there is a silent switch yet 🤔
I'll take a look at lunchtime ...
thanks for looking into tho! :)

[ewerybody]

So for the installer I'm using a couple of things:

1. 7zip sfx. It has a -y silent flag but I'm not asking the user anything there anyway. I don't know if its somewhere
2. a compiled Autohotkey script installer that checks out the environment and manages the actual copying and stuff.
   I wonder if my script receives arguments from the sfx. Or if there is something in the environment variables.. need to test.

The current 7zip sfx shows a little extraction progressbar no matter if -y or not. Maybe we actually need a separate package for silent installation. Wouldn't be much of a problem really. We could get rid of the progressbar right away.

One probably needs silent UNINSTALL right away huh?

[OlafHaag]

The preferred method would be that it can be made totally silent, installing as well as uninstalling a2. But there are packages in the chocolatey public repo that show some progress window and are only unattended. It's just really annoying if you're in the middle of doing something else.
What I absolutely can start with now is to provide the portable version. I'd only have to check if I need to shim the executable.
In the course of time there'll be 3 a2 choco packages:

• a2.portable
• a2.install
• a2 (virtual package, only has a dependency on a2.install for convenience)

These packages will each provide 2 streams: stable and pre-release.
There currently is only a pre-release available anyway. As a suffix to the pre-release packages I'd just use what's in the release info, e.g. a2 0.0.10-alpha. Regardless of the suffix, the pre-releases can then be installed by cinst a2 --pre.

[OlafHaag]

My virus scanner (avast) straight up blocked the download of portable version (because of a2app.exe). :(
It's recognizing it as "generic malware". This might cause problems for people trying to install the choco package later, so this file might need to be sent to avast and other virus scan companies for inspection, so they don't flag it anymore.

[ewerybody]

The preferred method would be that it can be made totally silent, installing as well as uninstalling a2. But there are packages in the chocolatey public repo that show some progress window and are only unattended. It's just really annoying if you're in the middle of doing something else.

Yeah for the progress bar to disappear we need to swap in another sfx binary blob. That's easy.
As it takes a moment to extract I'd rather have the progress bar for the attended installer because ux is nicer this way... Still I don't know how to pass args to the 2nd installer stage 🤔 but it would be possible to have a dedicated silent installer right?

What about things like user data on uninstall. What do the usual choco packages do? When there cannot be popups? Always keep user data I suppose?

[ewerybody]

Ah yeah shit. the antiviruses ... I checked our installer against virustotal a while ago. see #176
Now the whole zip is nagged about? Did you ever report such a false negative?

[OlafHaag]

What about things like user data on uninstall. What do the usual choco packages do? When there cannot be popups? Always keep user data I suppose?

I guess the user data would need to be kept, since updating a choco package internally uninstalls the old version and installs the new one. You wouldn't want to lose all your data with each update.

but it would be possible to have a dedicated silent installer right?

You mean an extra installer for choco? Sure. I just can pick it out from the releases if it's consistently labeled, e.g. a2_silent_installer_0.0.10_alpha.exe.

[OlafHaag]

Did you ever report such a false negative?

I did before with something else a long time ago. It took some weeks to hear back, if I remember correctly. I just reported the file as a false positive to avast and tried to make a case for it.

[ewerybody]

Is there a default location for choco packages? I mean I was always using user space of course. Currently we have:

• users/name/appdata/local/a2
  • data - user config and temp (kept on updates/uninstalls)
  • ui - interface of this a2 version (switched/removed on updates/uninstalls)
  • lib - runtime lib of this a2 version (switched/removed on updates/uninstalls)

I hope we can keep it that way?
Pardon me for not looking it up myself ... but you have xp there already: :D

[OlafHaag]

Usually with installable software, chocolatey uses the default install location given by the installer. Some installers take arguments for changing the installation location and these can be piped through to the installer with the --ia, --installargs, --installarguments, --install-arguments=VALUE argument of the choco install command, e.g. choco install git -y --params="'/GitAndUnixToolsOnPath /NoAutoCrlf'" --install-args="'/DIR=C:\git'". The /DIR= arg is native to the git installer in that case.
In the licensed (paid) version of chocolatey there's also a convenience argument --dir, --directory, --installdir, --installdirectory, --install-dir, --install-directory=VALUE which supposedly takes care of that, so the users don't have to figure out the correct native argument by themselves.

If the a2 installer takes such an argument, it'll be good to know.

For the portable version, I believe it's put into a location given by the ChocolateyToolsLocation environment variable. I think its default is C:\tools. Or it extracts the archive to where the choco package was saved, not exactly sure. I'll just have to create the package and see what it does.
The portable a2 version creates the data folder as expected in its extraction location once a2 is started for the first time. I think this is preserved during updates as it's not part of the unpacked files which get logged.

[Moosbueffel]

What's the current status? I searched at chocolately first for installation, but can't find anything. Now I foound this issue. And it seems to me that there were a lot of work done. So it would be sad, if this work will be lost.

[OlafHaag]

To my knowledge work is currently being done to provide a silent installer of a2 for the choco package. Once this is settled, I'll build, test and push those packages to the chocolatey community repository.

[ewerybody]

The installer building has been overhauled quite a lot.
It produces now 3 things:

• the standard installer executable with the extraction progress bar and the popups
• a silent executable version
• a "portable" zip file

I just didn't do a new release yet. Will do so at lunch :)

[OlafHaag]

I'm in the process of testing the choco packages for a2, but I'm running into a bit of trouble. Some of it may have to do with #176.
What's a good location for the portable archive to unpack to? I had the installer script unpack it into the location of the choco package, but that might cause problems with permissions, see below.

---

a2app: Error on "init_a2_win()"!

Could not call A2Window! Error:
error:
[WinError 5] Zugriff verweigert: 'C:\ProgramData\chocolatey\lib\a2.portable\tools\data'
Traceback:Traceback (most recent call last):
File "a2app.py", line 72, in init_a2_win
File "a2core.py", line 53, in inst
File "a2core.py", line 70, in init
File "a2core.py", line 256, in init
File "a2core.py", line 264, in _build_data_paths
File "os.py", line 225, in makedirs
PermissionError: [WinError 5] Zugriff verweigert: 'C:\ProgramData\chocolatey\lib\a2.portable\tools\data'

_ startup_error.log:

Traceback (most recent call last):
File "a2app.py", line 127, in main
File "a2app.py", line 33, in init
File "singlesiding\singleinstance.py", line 135, in ensure_single
NameError: name 'exit' is not defined

[ewerybody]

The zip should goto whereever you please. :) Of course it wound need to be able to write at its own place as well.

The silent installer executable is the one I intended for choco installation!
And that installs itself to our default install location ...\AppData\local\a2

This is also a user-space area where things don't need Admin rights!

[OlafHaag]

Around the time I posted here last, I started to work on the a2 choco packages, but I lost track of it and I don't know if I will pick it up again any time soon. So I decided to push what I had so far to a branch in my choco packages repo.
Here's the commit: OlafHaag/chocolatey-packages@038eb4d

Don't remember the exact state of the packages. There's some design decision to be made for uninstallation. When upgrading through choco it basically uninstalls the software and re-installs the new version. But you don't want to lose your scripts in the appdata. But when someone really wants to uninstall, they shall be gone. The same goes for the portable version. Choco keeps track of files that were extracted during unpacking. So any scripts installed would be left there by the regular removal process. But I believe it's cleaner to give the user the option to completely remove the software.
I think I was in the process of testing the packages and adding install options for these cases. Too much time has passed, I'm sorry!

I hope someone will test it and continue to work on it.