working on a favorite feature, which reads from the github repo if you starred a repo
- for now disabled git star/hearts since it sends too many requests to the github servers, overloading them.
- made plugget a lot more stable, fixing varioius bugs
- added URL button next to install. you can click it and it ll take you to the site from the addon. great to learn more about an add-on
- added advanced checkbox. if enabled it shows buttons to open some relevant folders, great for add-on developers who often need to access these, when debugging plugget.
- added a list button, showing locally installed packages
found an important UX bug that needs fixing
- if you have multiple versions of blender installed, packages installed in 1 version will show up as installed in the other, even though they are not.

Plugget now has a Qt UI addon for Blender.
This is slightly more advanced since it has PySide2 dependencies.
The benefit is that it also works in other apps such as Maya & Max.

rewrote the version handling since it had some issues with easily installing other versions.
now it’s very easy to swap between versions.
e.g. You quickly try a demo version, it breaks? swap back!
I wrote an installer script for plugget-qt-addon, that auto installs all plugget-qt dependencies and the plugget-qt addon. It can be found in the Readme installation steps.
The previous installation was a bit too technical, and plugget aims to make everything super easy.
Now that the installation of plugget itself in Blender has been streamlined, installing your tools has become even easier. ![]()
This is all interesting, how do you see plugget work together with rez ?
We are running all via rez and are starting to use blender… I have not looked at the code yet, but I once tried to simply have a rez package that loads a blender addon if it is present in the env, and I did not succeed to auto load the package, when blender is executed in that env.
For now I added all addons simply into our blender rez package.
But I ll give this a spin and see if it maybe covers my problems.
We have stored rez resolves/requests per project, or task, so we can define what is used where…
so if a show uses a certain plugin or whatnot, I would want to have the same level of control for blender. Artist launches blender on a task and the defined rez resolve loads the correct addons and when blender is launched he can use them…
I hope this makes sense, I dont want Artists to install anything locally on their own.
Atm rez is low priority. since rez support would be quite complex and time consuming.
I never had the opportunity to work in a studio that uses rez packages. but have researched it and am familiar with the basics. The main difference is that everything rez, needs to be launched from a rez launcher.
e.g. you cant just run a rez tool in vanilla blender AFAIK. but have to package blender in a rez package.
plugget aims to be very accessible. so if more studios start using rez i ll consider investing time in supporting it.
my current focus is
- create a nice UX flow for generic users. e.g. indie blender artists with no technical background, so the word will spread about plugget
- and support game studio setups, and try to get studios to adopt and contribute to plugget
I talked to one of the rez maintainers when i started 1year ago, probably should have another sync with him now that plugget has evolved so much.
- rez is great at handling clashing dependencies. and control your environment. it’s also very technical and doesn’t work with vanilla apps.
- pip is great at installing python packages, but does no environment control. and by default cant handle complex setup scripts.
- plugget is more like pip, it focusses on distribution. and comes with some premadde setup scripts for dcc apps. e.g. setup an addon, pip install dependencies, …
plugget has no environment control.
i prefer to separate distribution, env management, and dependency management.
this is kinda what plugget is all about.
empower the end user so they can install things on their own.
i come from a gamedev background so likely very different than VFX
a common issue i often experienced.
- if artists install tools on their own, they are forgotten, or wrong version, or they dont know how to install it.
- if tools come pre installed from a central repo. we prevent these issues. but if there is any issue in the tool, nobody in the whole team can work after they pulled latest in p4 or git. because a bug in the code can break the whole project or pipeline
a inhouse hybrid solution has solved these issues in the past.
distribute a list of installl buttonss for tools to the artist. they click install. and it will download and install the tool.
if the tool is broken, they can uninstall it. and continue their work without being blocked.
i didnt had versioning implemented at that time, which would have allowed the artist to roll back to the previous version of the tool that was working for them.
another pro of this approach was that often we distributed all tools to everyone. but an animator doesnt need back-end profiling tools.
plugget allows you to distribute tool-lists to each department. so people only see stuff relevant to them.
you still could use plugget for predifned lists of tools.
and run an automated install on startup of e.g. blender.
if this list lives in a central repo, you can update it externally, similar to a pip requirements file.
as long as you keep the UI hiding from the artists, plugget will then do what you want
A MVP of plugget is now also available in the competing 3d software Autodesk Maya
https://github.com/plugget/plugget-qt-maya-plugin ![]()
And fixed a few bugs I ran into during the implementation ![]()
Hey thanks for the in depth reply.
Rez works with Vanilla apps too, you can keep them out entirely if you wish too.
Atm at my place we do not have all dccs as Rez packages, but just resolve the env and then launch egg substance in that shell with the resolved env. I would not want to miss Rez, just to overcome python requirements and their deps.
But I will give this is a shot and report back how it all went.
I like your ecosystem of tools, unimenu, detect app already run at our place (in Rez via Rez pip). So thanks for all your work out in the open.
Now that I think of that I think I ran into an issue with detect app… but I will make a gh issue.
Maybe you could join the TSC Meeting which is once a month sometime to ask questions there, or the ASWF slack is also good if you would want to ask questions there is a dedicated Rez channel.
- I’m already in ASWF slack, but not an active user. I mostly use the tech-artists.org slack.
- To be slightly pedantic. When I say vanilla, I mean from the original app without env management. Since that’s how most users will launch it if they are not in a professional studio.
Your substance example uses a shell (env manager/launcher) to launch the app with a resolved env. So I wouldn’t count it as vanilla. - But it’s great to know this is possible and not only rez packages can launch the apps. I already started a env management project that would be compatible with this. so might give Rez a try once i go back to that project. Beta release: https://hannesdelbeke.gumroad.com/l/pdkqr
- and thanks for trying plugget, and for your kind words about the other projects, it’s always very helpfull to get user feedback

ye there was a bug, should be fixed in latest. I noticed your gh fork is outdated.
added tons of new plugins, plugget now can install 190 blender addons in total.
requirements can now be defined in the package manifest.
"repo_url": "https://github.com/fedackb/mesh-fairing",
"description": "smooth meshes without artifacts",
"actions" : [
["blender_requirements", [], {"requirements": ["scipy"]}],
"blender_addon"
]
}
this means you can point to a repo that has no requirements.txt file,
and define the dependencies in the manifest.
plugget now has a substance plugin https://github.com/plugget/plugget-substance-painter-plugin (which also can be installed with plugget
)

