Thanks, makes perfect sense. I knew I must be missing something. The arguments against distributing executables or non-universally compiled object files this way are obvious, but against things like these are less immediately so in the age of cheap storage and fast connections.
toggle quoted messageShow quoted text
On Mon, 12 Aug 2019, James Scholes wrote:
It's up to you where you place your packaged add-on files. There are some problems with putting them directly in the repo, which is why GitHub provides the releases feature.
For instance, once you've made 200 releases of your add-on (which isn't a crazy number given that sometimes you'll release a tiny bugfix), where are you going to keep the files? If you want to keep them around so people can pick and choose which version they install, you'll need 200 zip files in your repo. If I clone the code to help you with it, I don't want 200 zip files to come down with it.
This problem is only made more apparent when you're distributing something other than a 7KB add-on. What if the add-on includes binaries, sizable Python C extensions or audio files? Of course, there would be a way around it (as there always is), such as utilizing Git submodules. But at that point it's probably easier to just upload the artifacts to the releases area - or have AppVeyor do it for you - and call it a day.
On 12/08/2019 at 9:38 pm, Luke Davis wrote:
You can download anything directly from a repo, either preprocessed by github, or as a raw file.
Look at two lines from my recent review request for debugHelper:
Working Add-on File: https://github.com/XLTechie/debugHelper/raw/0.6-dev1/debugHelper-0.6-dev1.nvda-addon The first is a processed file: github converts the markdown to HTML. The second is an add-on package.
On Mon, 12 Aug 2019, Tyler Spivey wrote:
Because addons can easily be uploaded as a GitHub release.
Can you download .nvda-addon files from GitHub directly from a repo?
On 8/12/2019 1:26 PM, Luke Davis wrote:
Perhaps I am just being dense, but why does the .gitignore included with the addontemplate repo, exclude .nvda-addon files from being uploaded?
Being able to push the end result of an add-on package to a publicly accessible URL, seems like a perfectly reasonable outcome to me. Obviously it can be done by removing the line from .gitignore, or by using a force, but I am interested in the reason why this is the default.
It is not as if, in the vast majority of cases, the add-on package is likely to include compiled code, that may only run on certain platforms. NVDA itself only runs on exactly one kind of platform, so there are no non-portability of compiled binaries here, and as I said most add-ons don't include compiled code anyway.
I can understand if it is an issue of being concerned that the .nvda-addon file will become desynchronized from the contents of the repository, as can easily happen if new code is pushed, but no rebuild is done. However, if people are following the versioning scheme mandated by the community add-ons process, that will not be a real issue, as the add-on file will indicate its version number at all times, and if its stored in the master branch, some repo instability should be expected. If it's stored in the stable branch, I am back to my original question: what's the downside?
As an aside: shouldn't the repo be called "addonTemplate" in order to be consistent with other things?