I looked into the extensions part of v.4.2 a bit more, and have a question about the repositories.
Say if I create custom script directories to differentiate addon sets etc., and defined these in the preferences, can I add these custom script paths to the repository list?
e.g. I create a custom script location for the legacy addons, say 'Z:\BlenderLegacy\scripts'
Can I add this as a additional repository, so I can directly install addons into this location?
Or am I misreading the docs and functionality between repositories and custom script directories?
Oh…
And some of the DL’d extensions get really long filenames consisting of numbers and letters, which throws off the unzip functionality inside Win11
I did a few updates to the docs to make expected environment variables and paths more explicit. Though I’m not sure how to make examples very specific, since there are many different types of setups.
Legacy add-ons do not go in extension repositories, but the legacy addons scripts folder. Hopefully popular add-ons will be updated soon after the 4.2 release and this will become irrelevant quickly.
It would be good to support setting more things with environment variables, though custom startup scripts make the same things possible.
I think the long filenames might only be happening with extensions that were uploaded early and have not been updated since.
This used to work in 2.82, 2.83. But somewhere along the line, searching to user’s default preferences folder (as well as application themes doing this for you) stopped working. But yeah, you can literally just grab all the .py installed addons from one version to the other (machine or file path) and it would pick them up as your own (local) folder…
Thanks for the additional information in the docs on this. Much appreciated!
Especially for newcomers to/dabblers in python for Blender, this information is often hard to find, or to connect the dots regarding startup scripts, user preferences settings etc.
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.
