Custom extension for addon packages

Mac is just a symptom. Zips are archives, addons are actually Python modules... if anything they should be distributed as wheels, but I can also see why that's not the case. The only remaining obvious choice is to have a dedicated extension for Blender addons, much like Android has for APKs or Python for wheels.

"Zips are archives, addons are actually Python modules"

Part of the addon, not necessarily all. If the addon includes icon images, that's not a python module.

The use of .zip makes perfect sense, as most operating systems have a built-in method for creating and extracting them. The issue here is that Apple has decided to "Make Downloading Different". This is not a an issue limited to Blender - I actually did some searching yesterday, and "how to make Safari stop unzipping everything" is an issue for non-blender users as well.

Adding an optional ".BAO" support in addition to ".ZIP" is absolutely going to lead to Mac users emailing a dev and asking "When will you support the Mac", if they only see a zip file.

If the addon includes icon images, that's actually part of the Python module, much like any other Python module can include resources? There's even a specific mechanism in setuptools for this (called, unsurprisingly enough, resources).

And I think it's totally fair that addons developers get complaints if their addons don't install properly on a given platform - just like we do right now... the difference is, this idea would provide a solution. Whether addon developers choose to adopt it is then up to them, and indeed it's then fair that users will complain if the preferred installation method doesn't work for them.

EDIT: In addition, if I were to follow your logic to its fullest extent, we should be able to install wheels, and that's not currently the case.

No. The Mac OS issue is merely what triggered me to put this up here ; the reality is, as I noted, pretty much ALL modern file formats that use underlying zip have a custom extension. It could be used for a lot more than merely installing addons (say, for sharing assets or other things). The fact that it will also prevent breakage on Mac OS is only icing on the cake.

Also, can you please tell me how APKs and wheels "cause problems" ?

That's why it's supposed to be an alternative, not a replacement. The reason I'm posting this idea is precisely because we've had lots of reports of Mac users unable to install the addon because of this, so we were hoping to find an alternative that didn't involve the user tweaking anything on their end (that's why @thorn's solution below isn't OK to me).

An alternative just ultimately leads to confusion for the user and more work for other addon devs. Why are some addons .zip and some are .whatever? which one do i download? mac users emailing addon devs asking them to make a copy of every build with a different extension because they don't want to (or know to) uncheck a box.. addon devs feeling compelled to zip two copies of every release. hard pass.

If it's an important issue for you, I would suggest writing a custom installer that your users download instead of a .zip that unpacks your addon and puts it in the correct place.

Ye both have points there x)

Does OS X just unpacks the .zip, or does it also deletes the .zip?
In the first case, it shouldn't confuse users much. You still only have to fetch that .zip from Blender.
In the second case, I strongly think that adding more options for devs to ship addons "just" for that is overkill and will lead to the kind of confusion mentioned by testure.

That being said, maybe having a special file format could be used for other additional features.
For example, being able to just double-click .bpk would run a light-Blender that installs the addon (maybe with just an option to install in either the default or the user's custom scripts folder, just as when browsing for a .zip).

Be could also think about using .bpk files for different usages: like shipping asset. Addon devs and asset makers could have a simple file that describes the content of the .bpk, whether it's an addon, what files to include, and all that remains optional. Much like you already have the option between shipping your addon as an installable .zip or provide a bunch of files to manually copy/paste to the addons folder.

@-L0Lock- Precisely. The Mac OS issue is merely what triggered me to put this up here ; the reality is, as I noted, pretty much ALL modern file formats that use underlying zip have a custom extension.

EDIT: Also, they do delete the zip, I completely agree with you this would largely be a non-issue otherwise ; still, I think the feature is neat and provides more than merely a better UX for Mac users - as you noted we can probably use the extension for other nice things!

@testure How does it lead to confusion exactly? Addons can already be installed from zips OR mere py files, so adding an extra extension there (especially one that's DEDICATED to addons...) seems like the correct way to go here. As I noted, it's pretty much ubiquitous practice nowadays for any application using zip for more than mere archival.

@testure are you saying EACH addon developer should provide their own installer? That seems extremely backwards, compared to a single-line change in Blender sourcecode to allow addons to be distributed as .bpk...

EDIT: Also interesting from someone saying "An alternative just ultimately leads to confusion for the user and more work for other addon devs." meanwhile you suggest we ALL make custom installers. Meanwhile there's literally ZERO additional work for other addon devs if they choose to NOT adopt the new extension..... can you clarify?

The current "either .zip or .py" situation kind of works today because, aside from the issue you raised, they make no difference on the user side. You still install them the same way from the Addons preferences.

The only difference is on the developers' side, which is mostly just a matter of whether you developed an addon in a single file or not.
In the second case, you just ship a .zip. But most addons .zips are not manually generated to begin with, they are made by Github/Gitlab/whatever repository download button.

With the issue you bring here, it will create a situation where addon developers will have to consider making a different distribution for the Mac users who use Safari and don't set it up to not delete .zip files (which I find to be an amazingly dumb decision from Apple, but that's beside the point).
I bet most devs won't even think about it, won't even know about the issue, and thus never bother changing their workflow.
Other devs who know about the issue might still decide that it's up to the user to do things properly and prefer adding a few lines in their install procedure manual than going out of their way to make a different distribution for a few Mac users. (Mac users are not a majority, and < Mac users who use Safari with the setting to delete zip files enabled > are even fewer in the pool of users).

Some addon devs might decide to completely switch to .bpk files. But:

• they cannot rely on their repository host to generate the zip files for them anymore.
• they will instead need to create .zips manually, and then have to manually overwrite the extension, or write a script to automate that.
• users will wonder where are the zip and py gone
• users will send bug reports on other addons that have no .bpk

That's why, personally, unless there's a real added benefit to using a different extension, backed by the BF to automate things and make the communication to educate the users and addon developers, I fear just adding support for an arbitrary new extension will create confusion.

I was going to write a GHA to make artifacts use the new extension, so that's probably not something worth worrying about. On the other hand, I think it's a bit unfair to impose the requirement to the whole Blender addons development community to add extra instructions on their installation procedure, all because "perhaps" some users "could" be confused by a third extension being available.

EDIT: Gives me the exact same vibe as whoever said "just write an installer for your addon" earlier - meanwhile the standard is that addons are usually installed by the application they attach to.

Well yes there's always an unfairness somewhere in any change X)