Extensions Platform

Why not clearly described on the CHECKBOX?

“ALLOW ONLINE ACCESS TO EXTENSIONS WEBSITE” sounds more acccurate.

If I click “ALLOW NEGATIVE FRAMES” checkbox in another panel, does it allow negative frames on my files, or only on files that I download from the internet?

If I choose “Save as PNG” for a file option, does it save as PNG, or instead as MPEG if the destination is a network drive?

2 Likes

I think you’re arguing it’s strictly better in the sense it has moved some distance along the “no guarantee” to “full guarantee” axis. But landing in the awkward middle-ground in which Blender appears to make certain guarantees which may or may not actually hold according to certain complex conditions is actually in some ways worse than the situation at the extrema in which Blender very clearly either does or does not make a guarantee.

2 Likes

Even though this functionality isn’t there yet, the setting could also be used for Blender itself for checking on new versions for example in the future. This is not exclusively for the extensions platform as the tool tip clearly says.

1 Like

Please open your settings on your computer, choose the network driver, and click “disable network.”

Does the PC still allow connections for the browser, or email, FTP? Or is it actually disabled, as the button indicates it would be?

1 Like

If you’re system is secure, yes. If you have malware or a malicious program on your system though, this may enable it again in the background even without you knowing. The OS cannot prevent this. Neither can Blender prevent what a third party add-on is doing. And the tool tip of the settings says this pretty clearly.

I don’t know what else to say.

3 Likes

I say this respectfully.

The labeling is obviously not accurate. All of the reasoning given, points to why the software can’t control internet access.

It is almost as if the software does not want the user to know about this limitation except by offering a bit of insight with a tooltip.

The only conclusion that remains is that it is desired to potentially mislead the user. Or, not exactly being concerned if they are. Which makes no sense, but - that’s the basic result.

4 Likes

I’d guess that part of the problem here is that we are hoping to reuse this one preference checkbox for multiple things in the future, and that is making it more generic than it needs to be and read too broadly.

I’d personally prefer to see this “Network” section be called “Online Access”. then the current checkmark could say something like “Check for new and updated extensions” or similar. And if we later have other needs they can be added separately. “Check for updated version of Blender”, “Online AI Feature”, “User Chat”, or whatever.

Edit. Yes, this purposely leaves out mention of access permissions for the add-ons themselves. I think it fine to have guidelines for their well behavior, but I think what they do should just remain a contract between them and the user.

12 Likes

Perhaps a warning could be added that pops up when the user attempts to install an addon outside of extensions.blender.org with a “Don’t show this again” type checkbox akin to the kind you might get from your OS so that, at minimum once, the user is made aware of the risk.

P.S. Hopefully my previous questions weren’t perceived as negative, as clarification was my motivation, not criticism. And I found @brecht response informative.

2 Likes

When it comes to add-ons following preferences for practically *anything* it’s only ever a guideline.

We could have a special note for the “Temporary Directory” for example that extensions might ignore the temporary directory and use some other file-system location, simultaneous network-connections is only a guideline too.

Since “Allow Online Access” relates to security, it makes sense to consider it a special case and note explicitly in the tool-tip that the setting may be violated by add-ons.


To make it clearer all these networking options are only guidelines (without having to read the tooltips) the panel title could be renamed “Network Guidelines” or “Network Policy”.
Would this address your concerns?

2 Likes

At this stage you largely can’t. While the platform plans to have extension support for all those listed, as of right now and basically Blender 4.2 LTS forever, it will only support addons and themes as that is what they decided to focus on first.

1 Like

As already said node group assets aren’t supported yet in 4.2. Workaround what others are already using is wrapping assets in python code, so that you can have add-on that installs assets from .blend file in the .zip as asset library

1 Like

I have followed the docs section about bundling wheels and found results possibly contradicting the following statement from the docs:

Now installing the package will extract the wheel into the extensions own site-packages directory.

I have two add-ons:

  • addon_one

    • bundles wheels of pillow-10.4.0

    blender_manifest.toml

    schema_version = "1.0.0"
    id = "addon_one"
    version = "1.0.0"
    name = "Addon One"
    tagline = "Tagline"
    maintainer = "Author <[email protected]>"
    type = "add-on"
    website = "https://example.com"
    blender_version_min = "3.3.0"
    license = ["SPDX:GPL-2.0-or-later"]
    copyright = ["2024 Author"]
    platforms = ["windows-x64"]
    wheels = ["./wheels/pillow-10.4.0-cp311-cp311-win_amd64.whl"]
    

    __init__.py

    def register():
        print("REGISTERING: addon_one")
        import PIL
        print(PIL.__version__)
    
    def unregister():
        ...
    
  • addon_two

    • bundles wheels of pillow-9.5.0

    blender_manifest.toml

    schema_version = "1.0.0"
    id = "addon_two"
    version = "1.0.0"
    name = "Addon Two"
    tagline = "Tagline"
    maintainer = "Author <[email protected]>"
    type = "add-on"
    website = "https://example.com"
    blender_version_min = "3.3.0"
    license = ["SPDX:GPL-2.0-or-later"]
    copyright = ["2024 Author"]
    platforms = ["windows-x64"]
    wheels = ["./wheels/pillow-9.5.0-cp311-cp311-win_amd64.whl"]
    

    __init__.py

    def register():
        print("REGISTERING: addon_two")
        import PIL
        print(PIL.__version__)
    
    def unregister():
        ...
    

I use the blender --command extension build command to build both add-ons.

Installing addon_one from disk and then installing addon_two from disk results in the following output in the console:

REGISTERING: addon_one
10.4.0
REGISTERING: addon_two
10.4.0

While I was expecting to see this:

REGISTERING: addon_one
10.4.0
REGISTERING: addon_two
9.5.0

Upon checking C:\Users\%USERNAME%\AppData\Roaming\Blender Foundation\Blender\4.3\extensions\.local\lib\python3.11\site-packages it turns out only a single version of PIL was installed.

I was under the impression that each extension would get their own site-pacakges based on this comment in the docs:

Now installing the package will extract the wheel into the extensions own site-packages directory.

Is the observed behavior intended?

2 Likes

I said it before, and I’m saying it again. - insert meme with “Change my Mind Sign” guy -

The 4.2 LTS release should have been just that, a ‘maintenance’ release. Like all previous LTS releases.
It would have been better to introduce the extensions platform in Blender after the LTS release.
All this still doesn’t make sense - for me -.

And @ideasman42
It doesn’t matter what you call it, if it doesn’t do what it suggests it does.
I turn it off, but hey… it’s just a guideline/policy to ignore… Right? Right!?

Having the central extensions platform is THE opportunity to ‘soft force’ behavior like this to be controlled.
Having a checkbox set to OFF for internet access should do just that, no link back to the web from within the app.
Addons should obey that, and if that’s not technically possible have at least a text in the description that will say they override this access to function.

Could be that easy? Or not?
At least everybody than knows what to deal with, and can asses the possible security issues.
Like a studio dealing with a network based setup dealing with dozens of workstations and their own extension/addons setups.
e.g. If I block the blender executable in the firewall, can the addon still access the web?

1 Like

It’s about equally hard as sandboxing, so not practical.

A firewall will work.

If you are a studio disabling internet access for security, then I don’t think you would do that through a setting like this in individual applications. Because most major CG software doesn’t even have such a setting. Nor would it be particularly secure to rely on users to set this up correctly in all applications. So a firewall and router configuration would be what you use.

With this option Blender is going beyond what most CG software does, and giving regular users the choice as well, without having to be in a specially set up environment.

Also to be clear, software like Maya is not sandboxing third party plugins or add-ons either. They have some basic protections for embedded Python scripts as pointed to earlier in this topic, but that’s a completely different thing.

So as a whole, I think Blender meets whatever existing network access requirements there are for a studio.

7 Likes

Unfortunately it is. Wheels are in the “global” namespace so Blender will only be able to load one of the same module at a time.

If this becomes much of a problem, one idea we had was to list recommended version of popular wheels (pillow being the top-most) and suggest add-ons to stick to it.

In a way it is similar to the problem the VFX reference platform tries to solve but within Python modules specifically. I wish they would also provide a list of pypy modules.

1 Like

Could you please clarify one more thing for me so that I can be sure I understand this completely:

For example, add-on A requires package-1.0.0 to work and has indicated as such in its blender_manifest.toml wheels list. Then, a user installs add-on B that happens to require package-2.0.0 that contains breaking changes compared to package-1.0.0.

Does this mean that the add-on A will be broken, since wheels are scoped globally rather than per-addon?

If the wheel is not backward compatible yes it will potentially break add-on B.

I forgot now which one takes precedent (the old or the new wheel).

That’s a bummer. I was hoping the packaged wheels would be scoped per-addon rather than globally.

Thanks for the clarification, @dfelinto.

2 Likes

The newest wheel is used under the assumption newer wheels may include necessary features / fixes. So the only way to guarantee a spesific version of a Python module is to bundle it with vendorize or similar tools.

Ok, I made a mockup of Extensions UI that should make most people happy:


  1. No weird dichotomy between addons and extensions.
  2. Installed lists all the installed Extensions and switches the search bar to a mode better for filtering locally installed extensions.
  3. Get Online lists all the extensions available in Online repos, and switches the search bar to a mode suited for browsing them.
  4. Install from Disk just opens the good old browser window.
2 Likes