For anyone else looking to replace the old addon development workflow where you symlinked a folder under source control into Blender’s addons/ folder so it would update when you switch branches, this is how you do it.
Instructions for installing extension via symlink
-
Open Preferences ‣ Extensions and click the gear in the top right corner. Make sure there is a local repository (add one if there isn’t). The default one is called “User Default”. Click Advanced and note the path to the extension folder that appears there.
For example, on Linux I got ~/.config/blender/4.2/extensions/user_default.
-
Go to that folder (create it if it doesn’t exist), and create a symlink to your extension folder containing the blender_manifest.toml file. The name of the symlink should be the id from the manifest file. For example
$ cd /path/to/my/extension
$ grep '^id' blender_manifest.toml
id = "my_extension_id"
$ cd ~/.config/blender/4.2/extensions/user_default
$ ln -s /path/to/my/extension my_extension_id
-
Back in the Preferences ‣ Extensions dialogue, click the gear, select the local repo you used, and hit the Refresh/Check for Updates button (looks sort of like ↻). Your extension should now appear in the extension list. Use the search to find it, and enable it by ticking the checkbox next to its name.
1 Like
Installing from zip files will still be very important for customers. And not only zip files !
Just think about Github addons. That is a lot of addons / scripts & the devs don’t care about a useless new option / way. Also some of them are very old and aren’t maintained anymore…BUT WORKING fine.
Also important to mention:
I try to convince the blendermarket & gumroad staff, that customers should be able to see all updated files (from all the customers purchases) when logging into blendermarket or gumroad, so they know what to update, instead of scrolling through all sites of the purchases and click each one to see if there is an update. (if you can remember all version numbers for each addon you bought)
They are both not able to do so the last 3 years.
The extensions platform only would make sense for the blender onboard addons to slim down the filesize of the blender app install file.
Also autoupdate comes more and more from some developers and they work fine. Even for other installs like numba modules etc.
So this extension platform is pure nonsens from people who work for blender but not WITH blender !
The devs should more focus on finalising all the other intoduced stuff like light linking, asset browser, you name it. (all the half baked and basics like lights working properly …etc.)
SSS not scattering & contributing light to the scene…and that after the big overhaul of the bsdf shader + is now not on the scope anymore to fix… FOR EXAMPLE !!!
3 Likes
Since Blender 3.6 there’s support for multiple custom add-on directories, so workarounds like symlinking shouldn’t be necessary anymore (which wouldn’t work on Windows anyway): Python API - Blender Developer Documentation
1 Like
That doesn’t work for extensions, does it? (Also hasn’t Windows had symlinks for like 20 years?)
I guess the equivalent would be creating a new local repo for every extension, with the path set to the parent of the extension folder. I think symlinking is cleaner though.
Extensions will only be enabled in a couple versions (current stable Blender version is 4.0, extensions are planned for 4.2).
A “legacy” add-on is simply one that uses bl_info instead of the blender_manifest.toml file, that’s it. Even though it might still work it’s important for users to know that it’s using old APIs. It’s super easy to make a manifest file and convert any “legacy” add-on into an extension.
Also, Blender 4.2 is LTS (supported until 2026), by then —almost Blender 5.0, current add-ons will definitely be considered “legacy” if they use old APIs.
4 Likes
Absolutely, yes. I don’t plan to hook my blender software to gumroad, and every URL on github that has an addon I use. I’ll continue to eval if I want the update, based on the release notes, and install from .zip.
3 Likes
I understand that. It’s about the nuanced points of using that word.
Even though it might still work it’s important for users to know that it’s using old APIs.
The fact it’s using the old APIs is not related (at this time) to the addon function and compatibility, but only that it doesn’t “meet spec” of this new file hosting. Renaming all of these as “legacy” sends the wrong message.
3 Likes
Is it? I imagine that eventually users will have to do the following:
- download a .zip file from github/gumroad/blendermarket
- get an error when trying to install them because they’re legacy
- hopefully try again, this time selecting the legacy option
In the end, which API is being used is more of a developer matter than a user one. Couldn’t Blender recognize which extension is being installed? It’d be just a check:
- if the
blender_manifest.toml is included > install as new API extension
- if
bl_info is used > install as legacy extension
The legacy status of the extension could be provided in the extension properties, alongside the author name, etc. Why is it important for users to know what API is being used? And how can they know which one they’re installing? It’d be easier to just have a single “offline install” entry, as it currently is, and let add-on developers deal with the API switch.
8 Likes
In the manual:
In order to allow a smooth transition process, the so-called legacy add-ons will continue to be supported by Blender. They can be installed via Install legacy Add-on button in the User Preferences.
There is no button; it is a menu choice.
All add-on maintainers are urged to convert the add-ons they want to share, so they are future proof
Language is misleading, unless addons will be “future proof” against python API changes that can break an existing addon.
Converting a Legacy Add-on into an Extension /
Use wheels to pack your external Python dependencies.
For users that have no taken a step to learn all the intricate ways that one can work with python, the link being used does not concisely explain what a blender addon developer is meant to do.
If you have a pure Python package that is not using 2to3 for Python 3 support, you’ve got it easy. Make sure Wheel is installed… (pip install wheel) …and when you’d normally run python setup.py sdist, run instead python setup.py sdist bdist_wheel.
I’ve never run python setup.py sdist in the first place. Why do i have to do that now (I’m thinking, as I read the manual).
That website itself links to ANOTHER web site (labor of love link) which also goes into far more detail that may be needed.
The Blender documentation itself needs to explain the steps, and only that which is needed - not take the path of “go look it up yourself, here’s a link.”
5 Likes
I honestly don’t understand the negativity surrounding this?
Can someone tell me what exactly will be lost with this change? As far as I can see, If you choose, you can still use exactly the same addon workflow as you do now. All this does is add more options? What’s with the hate?
I mean “Install from Disk” and “Install Legacy Plugin” is fine as a differentiation if there actually is a difference in plugin architecture. I didn’t know that when I posted earlier.
Again - it is terribly important that blender remains at its core functional without internet connectivity. As an addon it will probably become the norm for most people as its conveinient. Companies just don’t always allow connections to the outside that easy.
But as I said: If “install from disk” remains a regular option and legacy plugins really ARE legacy plugins there’s nothing to really be upset about. It’s just that full offline functionality needs to remain. As Pablo also pointed out, though - there’s still a few more versions to come and improve upon.
2 Likes
By definition, it is not the same workflow we have now. The addon button is removed, and several new options have been added which can be improved in terms of the UX and the documentation.
Don’t confuse “concern” with “hate”.
This module is brand new, and will be used for years to come. It is not perfect as it stands now - that is reasonable, and expected. Few things are perfect right out of the gate. But the best time to address such things is before it lands into final release.
The first message of the thread states “We are looking for feedback on the different areas of the project”. That is exactly what is being offered here - feedback on the experience and process, not hatred.
3 Likes
What about developers who created a Blender add-on and have since passed away? How are they supposed to make a manifest file? What about developers who don’t have access to the internet due to global calamity or war? Yes, these are extreme examples, but they’re also real examples, I’m aware of Blender add-ons that fall into both categories. In a perfect world, the new system will work great, but there’s a lot of considerations about migration that clearly aren’t being considered. Before switching to a new system, you have to consider every possible edge case and make sure they’ll work
1 Like
Their addons have probably already bitrotted due to Blender API changes. Addons have always required either active maintainers to keep them working in new Blenders, or their users to use old Blender versions.
1 Like
There’s a lot of info here so far. It would help if ti was compiled into a guide of some sort so we know what it will take to support the new installs AND updates from a marketplace.
I understand there will be changes, I expect that every release or 2, and we just have to keep legacy copies for legacy users… that’s how it goes. We run into people all the time we need to support that are staying on an older LTS version for stability. Ideally we put in some version specific shims and move forward but I dont think we can do that after this change, it’ll be the old version vs the new version. If you need the new version of the addon you’ll need a new version of Blender etc.
One thing that is not clear to me in the discussions above is how marketplaces are supposed to support updates. I’ll ask in BlenderMarket and see if they have more info.
2 Likes
I put both a manifest and a bl_info section in my addon, and sofar so good, addon works on both 4.2 and older versions, but how long that’ll keep working, who knows.
6 Likes
That’s fair, I should maybe have used different wording. That being said, people seem to be getting surprisingly worked up by what appears to be a positive improvement that currently has some UI issues…
2 Likes
I think the concern is that all of the communications so far on the subject have been clear about this improving the free ecosystem. Which leaves a question as to what it means for the paid one. I remember Tons original presentation on this just saying “The market places will still be there…” but no mention of them benefiting from the improvements proposed.
I expect this will make it easier to distribute free addons. I have several to submit myself.
3 Likes
There’s no reason this can’t work for the market, the self host option with json is remarkably easy, it likely wouldn’t take much to give each user a unique repository url that’ll just have the addons listed they have paid for/subscribed to/spend their superfriends points on/howevertheyorganized it.
5 Likes
