I’m doing something similar for sharing add-ons. Now that Blender supports multiple repositories I think it would be good if there was “Bundle Active Repository” operator, that does all things for you and just gives you a single zip, which I could share with my students and they could run “Install Bundled Repository” operator, which will unzip everything in either default place, or custom path.
It would be especially useful if those operators remembered state of enabled/disabled add-ons and preferences. It would kind of defeat a purpose of this if students still had to go one-by-one to enable them.
I would personally upgrade manually for new versions.
A more general solution would be to allow bundling a custom userpref.blend and startup.blend as well, so that not only the add-on enabled state is preserved, but all the defaults can be customized. I’m a bit hesitant to do anything too specific to transferring add-on state.
Creating this can be a bit inconvenient if you want to do it without affecting the configuration for personal work. It could be doable with a temporary factory reset, some environment variables or a different user account. Not sure if this is still too technical if it’s documented.
I wasn’t so much thinking of having an operator that users would run to install this. But rather to have a directory next to the Blender executable that can be set up. So that it’s not really managed and kept up to date by individual users at all, but controlled more centrally, as might be done in a studio.
The operator case makes sense too. But it’s also tricky to support all these different workflows with different solutions. Ideally we’d have just one recommended way to cover all, if the trade-offs are not too bad.
There is an extension for browsers called “Tampermonkey”. It allows you to use custom scripts. You can export all of your scripts in one go. If you choose to export them to zip, then for every script there will be two additional files: script_name.options.json and script_name.storage.json that have all of the enabled/disabled options and other relevant information for every script. In other words, you can transfer all of the scripts from one TM to another and continue using them there without any problem.
When it comes to Blender, the same approach can be used but with some tweaks like choosing which addons to export/import (all or only enabled), whether to export/import custom shortcuts or not and so on.
I’m sharing userprefs and configs and stuff and you have to be very careful about that. There are some things that doesn’t translate well when you’re just shipping files
User libraries are being added and for students it just points to wrong path, so they have to manually delete it
Same for script repositories, and basically everything with filepath should be deleted, like external image editor
You have to be careful not to zip recent_folders (or what its called), so that it doesn’t return all greyed out folders in file browser.
I would love if assets were bundled too, but that would make zip files gigabytes.
I think just bundling repository and installing it is safest choice for now.
With the disclaimer that my own blender usage is personal, but I work in a corporate IT environment with heavy automation/orchestration/config management…
I like the idea of a directory that you can land in a known spot, and/or a config file in a known spot that points to your custom bundle directory. (EDIT: thinking about it, separating the config and the files would be nice, to allow for shared drive shenanigans but keeping individual prefs local after doing initial setup from a template.)
I think it would be sufficient to have a directory and not have blender do the unpacking. In the environments I’ve seen, any sort of automated push or agent pull system tends to package changes as a compressed archive anyway, so the tool will be doing doing the decompression for us.
What is the directory structure of a local disk repository like? Is it a bunch of archives+metadata? Can that be leveraged in a generalized way? e.g., could we have a type of uncompressed local disk repository that is flagged to automatically enable scripts inside?
(Putting on my security glasses for a moment though, any sort of automatic enablement needs confirmation–maybe a one-click enable instead, and only for file sources, not https).
It sounds like config separate from addons is an open question. Blender prefs/state of course have traditionally been packed into prefs .blend files. IF it’s a direction the devs want to adjust, this might be an opportunity to start refactoring or extending prefs reading from a json file like other posters have mentioned.
The idea would be to create it from factory settings, and you would only add file paths if you know they are going to work, which in some cases is what you want. The default assets folder may need some work, but that’s not so difficult.
The manual bundle installation step I think is fine for a certain use case, where you tell every user to install something once for a course or something. In e.g. a studio environment where you have the particular version of everything more tightly controlled, maybe different depending on the show, that’s not how it’s expected to work.
I think perhaps application templates are a good way to handle your use case, without introducing new concepts in Blender. For example it’s possible to create a template that contains add-ons plus an __init__.py script that enables them. This can optionally also include a startup file, preferences, etc.
The downside is that not many know how to create such application templates, and it’s quite technical. But perhaps there could be an operator to create templates like that. Could even be implemented and maintained as an extension, by people familiar with what works best for teachers.
Yes, that was the idea, to have a separation between bundled files and local config files. Otherwise users would have to manually update and merge with their local configuration all the time.
It’s sort of a folder with some uncompressed extension zip files, but there are specifics which make setting it up manually not trivial. So I’m looking at how to make it easier to set up and do something like this.
I don’t think so. If someone is automatically deploying software for users, then I don’t think the user needs to confirm anything regardless if it’s Blender itself or an add-on. If the bundled add-ons are stored in a folder next to the Blender executable, then anything that can write to that already has permission to change Blender itself anyway.
Different config file formats is not something I want to go into, that’s a much bigger topic than I have time for. Even doing it for some subset related to add-ons would still lock us into design decisions made before the whole thing is figured out.
Thanks for listening to community feedback on this, I personally (and many others) really appreciate it. I know we’ve butted heads in the past, so I just want make sure it’s clear how much these updates are appreciated
Thanks for this! I hope to see a native Rigify be implemented as well since its an extremely useful addon. Thanks for all the amazing work y’all do! I’ll be donating more to the monthly development because of this
Having more options to ‘shuffle’ data folders around would be really nice, now that we’re going through these changes.
For small studios/schools/training institutes wanting to automate things, it would be nice to have some more options to set various environment variables.
So being able to point all the user data away from the default locations to s newly set location.
If so, please add more information to the documentation, as the current info on this is very sparse.
The addition of being able to set multiple addons locations and asset libraries is already a great step for this, but it would be nice if Blender makes it a little easier to move user data around, like with other 3d apps.
I would love to see some examples on how to properly implement the environment variables.
I also use custom application templates, and having multiple ways of setting paths and system settings is a bit annoying at times.
Like other 3d apps it would be nice to set most of it during launch via env variables, and then have a custom template ‘on top’ with e.g. another theme, keyboard prefs etc.
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.
