Hi, is the file size limit for the .zip file final, or is it possible to increase the 10MB file size limit? We have just recently switched to packing binaries instead of implementing everything in Python, because dependencies felt like a western and users were frustrated. Even if we would not switch to binaries, I would need to bundle for Python 3.10 and Python 3.11 for 3 platforms and 2 architectures if I want to support 3.3LTS-4.1+. I believe this to be reasonable strategy, but it is way over 10MB limit. Thank you for the info, btw the platform’s great!
I think it’s a shame not to offer more visibility to content in the process of being validated, there may be an addon I need in this list!
Plus it allows you to prioritize the most downloaded addons.
Either by adding another space.
Or simply by adding an option to display unvalidated content.
I discovered some interesting addons in the “Approval Queue” list.
It was frustrating to browse
I’m not sure the Approval Queue List is intended to be browsed in the same manner as the Approved?
It’s akin to a back-end inventory listing, not a front-end shopping cart.
When you say “there may be an addon I need in this list!”, you’re ignoring the fact that it hasn’t been approved. There might be a significant issue with it, such that is NOT approved and released.
I highly disagree with this idea. Unapproved extensions shouldn’t be made easy to download or instal for a regular user, this will lead to situations where malicious people will upload an extension with malicious code and affect a lot of users. Having the unapproved queue in the list format gives the impression that persons who knows what they are doing can download and moderate.
8 Likes
I’m well aware of the security issues involved
I’m afraid that if the platform expands, the waiting lists will become very long. Classic users should at least be able to choose which addons to check first, perhaps through a voting system. I think we need to find a solution to make the verifiers’ work easier.
2 Likes
Hi, after a little hiatus due to GDC, there are a few news:
-
The backend team who originally worked on the platform (2 years ago), is back and helping wrapping up the tasks. The next steps are listed here: 2024-04-02 Extensions Platform - Backend
-
We just did a big disruptive update today, changing the file format the site sends to Blender. To continue testing the Extensions platform please update to a newest Blender, and “Check for Updates”.
-
For anyone hosting their own JSON, you will need to update your JSON:
blender --command extension server-generate --repo-dir=/path/to/packages.
For the backend the focus is on bringing the features that are required for moderators to join the project (mainly notification). To smooth some rough edges, bug fixes. Then eventually multi-OS support for extensions.
For Blender, the next big thing is to handle the Splashscreen changes for users to opt-in for checking for updates upon launching Blender. As well as handling the existing legacy add-ons currently bundled with Blender.
14 Likes
From a discussion with @dfelinto about the status of community add-ons bundled with Blender, the conclusion was that maintainers were encouraged to migrate their add-ons to the new platform, because they would eventually be deprecated.
Writing a manifest file should be straightforward, but one thing I find important and is not always trivial is to extract the add-on file or directory to its own repository, to host it externally.
An easy way to migrate an add-on is to simply create a new repo and commit the code and manifest there, but that loses commit history. I think that would be a shame as it’s valuable both for crediting the authors, and to navigate the history for debugging purposes.
I had a look at how one might go about doing such a migration.
The gist of it is:
- Clone the
blender_addonsrepository. - Rewrite the history using
git filter-repo, to get rid of everything not related to the add-on.
For some situations it’s quite simple, but there can be complications. I’ll take the first add-on as example, add_camera_rigs and show a way to migrate it. This assumes some familiarity with git!
Lotsa commands
### Getting the code
cd /tmp
# Start by cloning the blender_addons repo
git clone https://projects.blender.org/blender/blender-addons.git add_camera_rigs
cd add_camera_rigs
# Look at the history of the add-on from the bottom to know if the files were moved
git log --reverse -- "add_camera_rigs"
# If we go back to the first commit, we can see that the add-on was
# originally in a file called camera_dolly_crane_rigs.py. So let's
# look at the history for that as well.
git log --reverse -- "camera_dolly_crane_rigs.py"
# This commit tells us that the add-on was originally in
# blender_addons_contrib under the name rigging_camerarigs.py:
# https://projects.blender.org/blender/blender-addons/issues/51067
# Let's fetch that as well to get the whole history!
git remote add contrib https://projects.blender.org/blender/blender-addons-contrib.git
git fetch contrib
# Create a branch for this remote, so we can use its commits
git checkout contrib/main -b contrib_main
# Look at the ancient history
git log -- "rigging_camerarigs.py"
# After we've downloaded quite a bit from the Internet, now is a good
# time to make a backup
cp -r /tmp/add_camera_rigs /tmp/add_camera_rigs.bak
### Grafting
# If we have a thorough look at the log, we can see that the graph is
# interrupted. This is because there are actually two histories in
# this repo, one for addons and the other for contrib. They are
# completely disjoint right now. Let's make a single history out of
# them, to pretend there only ever was one repo
# For that, we'll first use two commands that get us the first commit of
# addons and the last commit of contrib:
git rev-list main | tail -n 1
# 79d89af92401a7db16d4e0c86c6126d603eaef1b: first commit of addons
git rev-parse --verify contrib_main
# 16908cc466f41d6313b2c1891bb37706fc76fb51: last commit of contrib
# We'll perform a graft of addons onto contrib
git replace --graft 79d89af92401a7db16d4e0c86c6126d603eaef1b 16908cc466f41d6313b2c1891bb37706fc76fb51
### Rewriting the history
# From looking at the history before, we know all the files we want to keep
# from the two repos' histories:
# add_camera_rigs camera_dolly_crane_rigs.py rigging_camerarigs.py
# We'll use git filter-repo to get rid of everything else.
# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
#
# THIS WILL MESS UP YOUR REPO, DO NOT USE IT IF YOU DON'T WANT TO LOSE ANYTHING!!
# This is why we made a fresh clone and a backup just in case.
#
# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
# Filter the repo, specify each file and directory we want to keep with --path
# We'll use the --force option to tell filter-repo that we know the risks,
# and --replace-refs delete-no-add to "bake" the graft into a single real tree
git filter-repo --path "add_camera_rigs" --path "camera_dolly_crane_rigs.py" --path "rigging_camerarigs.py" --replace-refs delete-no-add --force
# Now if we have a look at the history, we can see that only relevant
# files remain, the entire rest of the history is gone.
git log --all --graph
# Go back to the main branch
git checkout main
### Editing for use as a standalone repo
# Currently the code lives in a dir called add_camera_rigs.
# We may want to move all the files to the top level.
git mv add_camera_rigs/* .
git commit -m "Move files to the top-level directory"
# A lot of tags remain in the history. We could keep them but if we don't want to:
git tag | xargs git tag -d
# Similarly, there are a lot of branches, we can get rid of everything except main:
# This works because we're already on main and it won't be deleted.
git branch | xargs git branch -D
# Get rid of the remaining remote
git remote rm contrib
# Add important files
touch blender_manifest.toml
touch README.md
touch LICENSE
# Edit those to suit your need, then:
git add *
git commit -am "Add manifest, README, LICENSE"
# At this point we can push to a new repository we've set up online!
If someone needs to migrate their add-on but finds this confusing (wouldn’t be too surprising 
), let me know if I can help with that.
6 Likes
After reading through your commands in entirety, my confidence that few to no developers are going to do this and the extension platform will dwindle away into obscurity from lack of new content is now firmly at 100%
I mean if they don’t want to do that it’s fine too, just offering to help.
1 Like
As far as I can see, that script is just a guide for maintainers of addons already bundled with Blender to extract their addons commit history from the monolithic blender_addons git repository, and into their own separate repo. That’s something that ~99.95% of addon developers will not have to worry about.
For me, it was as simple as adding a blender_manifest.toml to my addon and the conversion was complete. I’m really not sure where your distaste for this project comes from.
9 Likes
that script is just a guide for maintainers of addons already bundled with Blender to extract their addons commit history from the monolithic
blender_addonsgit repository
That’s exactly it!
2 Likes
As was mentioned here before, it was a bit clunky to access the 
(Repositories) menu. The ideal solution for me would be to introduce a 1 or 2 seconds timer before dismissing the popover. However since we don’t have this at the moment, we moved that menu inside the Dropdown menu.
This is very unusual since it is a popover menu, called from a dropdown menu. However it seems to work(?). The strange part is that it opens on the right every time.
I will leave for the User Interface module to iterate further on that (Pablo was already involved on this design with me, but I don’t mind being out of the loop to focus on other parts). Meanwhile feel free to share your opinion:
- I’m indifferent
- It is fine as it is
- It is worse than before
0
voters
Additionally, we now have a design for how we introduce users for the first time to the matter of “access to the internet” (for downloads but also to check for updates on startup):
Personally I would rather have two rows of buttons as in PR #27. I don’t think trying to make the UI more compact here is helping.
8 Likes
I read in one of those discussions, that one reason for these small little buttons and other things being hidden behind tiny menus, is to sort of enforce the workflow of the user going with automatic internet checks and updates when blender launches.
It’s for what it’s worth, I don’t believe I’d ever use that sort of auto check update feature when launching blender.
I read the release notes for every add-on that I update. And at that time, I decide if the update is worth installing, versus possibly affecting my workflow in a bad way. So I am not going to use an update all button, just pull the trigger and hope for the best.
I’m sure I’m not the only person who takes this deliberate, cautious approach. So given that, I believe that designing a UI that sort of “hides” certain commands, or makes them more tweaky to use, is overlooking something in the bigger picture.
ETA: I’ll also note that this part of the application is a preference dialogue that is not used all day long when creating things in blender. I don’t think so much focus needs to be on elegant rows of icons. When adjusting commands and options that affect the entirety of the software, clear button labels and usability is the most important thing, not minimalistic layout.
1 Like
I read in one of those discussions, that one reason for these small little buttons and other things being hidden behind tiny menus, is to sort of enforce the workflow of the user going with automatic internet checks and updates when blender launches.
I think the naming of some of the operators was a bit unfortunate and is leading to a few confusions.
To make things clear: There is no proposal to automatically update add-ons.
What we want to automate is getting the list of available extensions from the enabled repositories. I’m updating the current proposal now based on the latest feedbacks.
I will leave for the User Interface module to iterate further on that
Let me rephrase it, I’m happy to leave for Pablo to iterate this further together with the rest of the User Interface Module.
I think there is much to be gained by including his voice on the discussion since he has been following the project close by from the beginning.
The extensions feature is now officially in Blender 4.2 and the website is now officially in Beta.
To read more: Extensions Platform Beta Release — Developer Blog
I will close this thread for now, thanks everyone for the testing and feedback.
I will open a new thread later now that things are more stable and in main. Meanwhile you can share feedback on the #xtensions-Platform-Project-feedback chat channel.
7 Likes