Would there be a way to make installers that work from the ZIP generated by the GitHub “Code” button’s “Download ZIP” menu item?
I do not know what mods the Windows AIO installer or macOS bundle have to add to the Master repository files to create something compatible. (Are they adding .ini files? Swapping in alternate modules? Omitting incompatible modules?) But perhaps it is something that can be scripted to use the ZIP?
Could you share what this would achieve? Are you thinking about saving on the effort of creating the installers?
From what I can see, the “Download ZIP” functionality is available only at the root of the Git repository and simply creates a ZIP file of every file in the repo and sends it over the wire. Haven’t seen any customization options for it.
Hopefully, it would be a path for more users to jump into beta test of the most current code.
Excellent thought. Curious, what does it take today to build the installers?
Building for the AIO is not for the faint of heart; see the Building Gramps AIO cx freeze-based - Gramps for details.
Ill let others respond on building for MAC or the Linux distros.
Wow, you’re not kidding! Based on the current process it’s hard to see a path to a one-click generation of an installer. Small steps to automate part of the process may be a place to start.
Why not eliminate Windows of the equation?
Like not providing a Gramps AIO installer/package for Windows but an AIO installer to install (Docker if needed and) a set of Docker containers based on Linux to run Gramps on Docker in a Windows (or Mac) box?
The important thing for a Windows user is to have a procedure wich automate the installation, what it’s running on is transparent. Gramps containers already exists, their installation have just to be automated.
(Or a procedure to install a linux distribution of Gramps, and its dependencies, and make them working on WSL? But Docker seems me simpler)
Eliminating Windoze and using docker would eliminate the OS specific Beta Test. There are definitely Windoze specific bugs that need to be tested.
You want to eliminate approx. 66-67% of everyone that downloads Gramps ?
the last 2 years it is 5 times as many Windows as Linux users that have downloaded Gramps from Sourceforge.
Adding the complexity of using docker or WSL for Windows users will only lead to this user group being chased away from Gramps… In practice, that is, the same as stop supporting Windows as a user platform, not everyone who uses Gramps is OS superusers or developers.
I definitely agree that the current Installers are better for a final release. Changing that would be a misstep.
I am only suggesting this for beta & alpha testing installs. As Paul pointed out, creating the AIO installer for Windoze is a significant task. So building an installer isn’t likely to be done (or done frequently enough to be effective testers) for the larger Windows community to participate in a beta test cycle.
(It is coming up on 3 years since 5.1 upgrade release. Some significant enhancements have been in the hopper all that time. Some of those could have been thoroughly tested by now if it was more straightforward for a non-developer to set up a testbed.)
As a side note, the Linux community is largely invisible to the downloads statistics gathering tools. Since it is bundled in a broad number of distributions, we cannot guess how many copies are in use. (Windows is still likely to have the lion’s share simply based on comparative userbase scale of OSes.)
Unless the Gramps-project migrates the addonlist to a server where we can gather administrative statistics, there aren’t going to be any firm numbers on versions in use or the OS distribution. There are just too many distribution channels that we cannot track.
But that will not help to get Windows faults tested and fixed, will it?
Regarding the downloads… and the stats I linked to; it was an example.
But since most distros have Gramps 5.1.3 or lower version in it as default, you can actually get a picture of who uses it actively, by taking a look at the downloads of the updates on Git and SF…
Most statistics are made out of a percentage of what’s the actual numbers…
If the ZIP installer applied Windows patches instead of using a Linux emulator, then Yes, it should help debug Windows faults.
(Although it would NOT help resolve faults with the AIO installer itself. i.e., the default to UK English dialect spell & grammar checkers … when everything else in Gramps defaults to US English.)
I thought you were talking about Docker / WSL…
But… this is not my table.
I need to sit down with that wiki page and a highlighter.
Maybe there’s a hybrid Frankenstein that can be stitched together. Where it uses the 5.1.5 AIO installer to create a renamed destination and scripts an overlay using the ZIP from the GitHub master. A multi-step process that isn’t beyond a user willing to do a bit of work & risk accidenttal electrocution.
The Installer build automation was improved during the 5.2 beta cycle.
GitHub has an API that allows a folder to be ZIPped and downloaded. (for more, see the Notes)
And there is an Isotammi ZIPinstall addon to do installs of Addons from downloaded ZIPs.
So I wonder if Gramps couldn’t have a feature where the user maintains a list of GitHub Repository URLs (and/or local URIs) used to build a local project repository with a download folder full of .tgz files and a listings/addons-en.json (Similar to the make.py file from the Gramps addons-source repository. It builds an Addon&nbps;Manager compatible addon list).
It is important that the list is not be buried in a GUI. Being able to paste a list into (or copy from) the fault-tolerant maintence tool would make sharing a list simple.
As a bonus, that process could check that the just-built project repostitory is in the Addon Manager’s list of Projects and offer to add it if necessary.
Perplexity AI notes on the GitHub download API:
To download a specific folder from a GitHub repository via API, you can use tools like “github-files-fetcher,” which is a command-line tool designed to download a single folder or file from a GitHub repository. This tool allows you to specify the folder you want to download, making it convenient for extracting specific content from repositories. Additionally, you can refer to resources like the one provided in the first search result for more detailed instructions on downloading private GitHub repositories via API.
