I updated this announcement description with the latest information about the “popular (hacky) add-ons”:
Popular (Hacky) Add-ons
Some add-ons are widely used, however they were never to the quality standard expected of the core Blender code or usability. They will be moved to the extensions platform.
Node Wrangler
Some of its functionaility can eventually be integrated into Blender. But as a whole the add-on belongs elsewhere for now.
The Physics & Nodes module decided to bundle it with Blender as a core add-on. So over time some of its functionality can be merged as native tools.
Import Images as Planes
It uses: bpy.app.driver_namespace, bpy.app.handlers.depsgraph_update_post & bpy.app.handlers.load_post in ways which runs too frequently.
Incorporated into Blender as a native tool (Shift + A > Images > Mesh Plane)
Rigify
It is one of the many possible solutions for auto-rigging. The animation & rigging module is ok with being an extension for now.
Animation & Rigging module decided to bundle it with Blender as a core add-on.
Hi @dfelinto, is there currently any plan to also include Loop Tools as Core, since it currently the most downloaded and used add-on on the Extension platform? Or at least port over some of the most used operations as defualt operations, like what was done for image as plane and node wrangler.
There currently no plans for that as far as I am aware, but there is definitely a desire to push Blender functionality forward and bring it to the new levels. Is typical issue of limited resources and time.
It would be cool to have a community support for that as well, to make this extra step of submitting a PR which expands the core functionality for everyone.
Would a patch of, for example the circelize and the relax operations from Loop Tools to default Blender be accepted? If anyone, hypothetically worked on it?
Even if its still in Phyton, the current performance/functionality of the phyton operations are more than acceptable in my opinion.
Maybe I’m missing something here, but I’m entirely confused with this local and remote repository thing. Two things I currently run into:
I can add a local repository following the manual, and convert my existing custom Add-ons by supplying the blender_manifest.toml and put it into that repository folder. But this whole system acts like an Add-on folder. It’s not a repository from which I would then be able to INSTALL my Add-on from. Instead, this simply becomes my Add-on folder. Nice per se, but not what I would call a repository. I’d like to supply a repository to my employees, so they can install Add-ons from it locally on their machines from a Network Drive location
I can run the blender --command extension build or validate commands just fine without throwing any errors. The extension with the ‘limitation’ stated above also works. But the blender --command extension server-generate command never finds my extensions, it always reports back found 0 packages. Is there a video tutorial showing the whole process please? Kind of like “this is how it’s done” on a simple example
I didn’t check details of implementation, but on a technical side it is fine to have functionality implemented in Python. Is not like all the functionality exposed in Blender is written in C/C++, there are some tools and IO which is in Python.
Great, this worked and produced the .json file required. Now the question is, can I use this output as a repository hosted on a Network Drive instead of a Website?
Looking into this as well.
But if you set it up atm, can’t you just add the new repository to the prefs?
That way your addons should show up. At least if I’m understanding it all correctly.
This works after a few tweaks!
Not sure if this is a Windows Platform thing, or just spaces in the path I had used before, but using a setup like this the extensions show up and are ready to install:
Drag and Drop of any of the extensions (without manually adding the repo to Blender first). Blender asks to add the Repository to the system first, but produces an invalid configuration
Using the platforms tag in the .toml. There is an error thrown on package generation, see below
note the file path in the config, which is incorrect:
Note also that for some reason, the repo path in my working example above has to be typed as file://xxx, NOT file:///xxx - maybe a Windows only thing? Should be three slashes normally?
Actually the initial problem is that you have a trailing
comma inside your list. But yes, you also need to use windows-x64 instead of amd64. And Blender should have given you a proper error.
Unfortunately none of the suggestions work (tried all of them), the error is related to how the data is interpreted in Python. It makes sense, the code in blender_ext.py reads:
platforms = [platform for platform in manifest_dict.get("platforms", "").split(",") if platform]
and throws the error 'list' object has no attribute 'split'
which is correct, given that manifest_dict.get("platforms", "") already returns a list as defined in the .toml. If it were a str instead, the code that tries to split it would make sense.
For the records, I think the only “problem” here is that the generated html has repository=“./index.json” for all the entries.
Short of suggesting people to manually search/replace the index.html, this could be an option --html-repository where you specify the entry point for the json.
On a different subject, how would one now enable Add-ons via command line?
I used to do for example this in Blender 4.1: blender -b --factory-startup --addons "f2"
to load an unbloated Blender and just activate the f2 Add-on (as an example). If I provided a wrong Add-on name, e.g. blender -b --factory-startup --addons "foobar", Blender would report back: Add-on not loaded: "foobar", cause: No module named 'foobar'
With 4.2 I can’t activate any of the Add-ons at the moment with such mechanism. Furthermore, the error message isn’t telling me much, and is always the same:
Traceback (most recent call last):
File "<string>", line 1, in <module>
ModuleNotFoundError: No module named '_bpy_internal.addons.cli'
