Extensions Platform - Alpha launch

[SpookyDoom]

@Andrea_Monzini

The question is : if an extension under only GPL license and have some assets ( textures for example ), do you need the attribution for the OUTPUT renders if the renders contain the assets references ( like textures) ? In other words are rendered textures considered an OUTPUT of the GPL licensed texture ?
GPL License is not well suited for assets.

That was never the case. Of course there is a grey area like if you just re-render the texture as is and it’s essentially the same as before. But as part of your rendering the rendering can still be your license of choice. Sort of like you can’t just take photographs of random people and publish them but if they are just part of a publically available scene and not the main focus it’s permitted.

obvious disclaimer: this is not binding legal advice and as always if you want to be on the absolute safe side you need to ask a lawyer.

[Lumpengnom]

Is there a way to declare which thumbnail is shown on the extensions main site?
My addon was taken down because of text on the thumbnail and after re-uploading a version without text the preview thumbnail is now a different thumbnail.

[pablovazquez]

Thanks for sharing! This kind of bugs are better suited as bug reports on Issues - extensions-website - Blender Projects so we can keep track of these issues and close them when fixed.

That being said, this particular issue we will probably tackle by adding a new field for “Featured Image” or similar, to be used for thumbnails, social media sharing, etc. We also might add icons/square thumbnail soon.

[brecht]

@SpookyDoom

That was never the case. Of course there is a grey area like if you just re-render the texture as is and it’s essentially the same as before. But as part of your rendering the rendering can still be your license of choice. Sort of like you can’t just take photographs of random people and publish them but if they are just part of a publically available scene and not the main focus it’s permitted.

Not really on topic here, but I don’t think this interpretation is correct. I think the default assumption should be that if you use a texture, you need to respect its license for your final render too.

Which is why CC0 is most convenient, as you don’t want to worry about licenses when just creating things in Blender with assets available by default.

[ideasman42]

@Spencer_M

Many of my questions were answered from the docs, except one edge case. How will this affect installing add-ons via Python API? I currently run unit tests on some of my add-ons, which installs the add-on for the test session (you can see the install code here, if you’re curious). The module reference would need to change, from what I understand about relative imports. But any insight or examples would be greatly appreciated.

@Spencer_M for a unit test it makes sense to setup a new repository pointing to a temporary directory (which gets removed after the tests run) and install the extension there.

This is done in scripts/addons_contrib/bl_pkg/tests/test_blender.py, however I expect changes to this part of the API, an alternative which should be available soon is to use command-line arguments install the extension.

[LazyDodo]

The permissions section in the manifest, how exactly does that work?

I put permissions = ["network"] in my manifest, then stuck the following code in my addon

f = open("demofile.txt", "w")
f.write("Hello World!")
f.close()

and even though the addon clearly didn’t have files permission, it was allowed to operate on them and created the file without issue.

[LazyDodo]

@ideasman42

I can redo this error and will check on this next (edit now fixed).

I can’t seem to confirm this, all issues from point number 2 in this message are still a problem for me. Maybe it’s my json, unsure, but my for testing my test addon repo can be found here .

heads up: testing repo, not meant for end users, the only addon in there will try to write that demofile.txt file mentioned in the post above currently.

[LazyDodo]

I’ll admit, it’s was a bit of a bad faith move, but if you trick a user into adding a rogue repository, with lets say 5000 addons in it, the prefs menu pretty much becomes an unusable lag fest.

LazyDodos house of lag.json (don’t think this needs a warning, but end users: DO NOT ADD this repo to your blender, your will have a bad time getting rid of it)

Additionally, malformed json, fails silently when updating the repository

LazyDodos house of errors.json (Looks valid, but the extra comma after the last record, upsets the json parser by the looks of it)

[nickberckley]

I was also thinking about it as extenensions platform grew. It is not very usable. If it was semi-browser where you could browse images and reviews maybe, but its a long list of names. What benefit are you getting from it? Only one is searching for addon and installing, but in order to choose one you need to go to website anyway. Might as well drag and drop from there.

And I’m also curious what will the prefs look like when extensions has hundreds of addons and themes on it

[Zsolt_St]

@Shwaky

This already exist. you can download and install an addon manually. see example this addon on the extension page

Yes, as I said installing manually works. What I mean is, if I go to Edit → Preferences → Extensions, and click on an extension, there is nothing to click on, just Uninstall. The Wireframe Colour Tools for example:

A link to the Extensions Platform webpage of the given Extensionwould be nice.

[ideasman42]

Basic command line access is now supported for typical operations, see extension command-line docs

This exposes a build command which builds & validates a package from the blender_manifest.toml.

e.g.

 blender --command extension build

Builds the package in the current directory, there is a validate command too.

---

@LazyDodo I’ll have to double check on this, I was getting an error that looked exactly the same as yours on a newly added repository, if your still getting an error then it’s likely a different issue. I’d prefer to handle that via the but tracker though.

[LazyDodo]

@ideasman42

I’d prefer to handle that via the but tracker though.

Not a problem, #119461

[SpookyDoom]

@brecht

Not really on topic here, but I don’t think this interpretation is correct. I think the default assumption should be that if you use a texture, you need to respect its license for your final render too.

Which is why CC0 is most convenient, as you don’t want to worry about licenses when just creating things in Blender with assets available by default.

̶T̶h̶a̶n̶k̶s̶ ̶f̶o̶r̶ ̶t̶h̶e̶ ̶c̶l̶a̶r̶i̶f̶i̶c̶a̶t̶i̶o̶n̶ ̶b̶u̶t̶ ̶i̶t̶’̶s̶ ̶a̶l̶s̶o̶ ̶m̶o̶s̶t̶l̶y̶ ̶w̶h̶a̶t̶ ̶I̶ ̶m̶e̶a̶n̶t̶.̶ ̶I̶ ̶w̶a̶s̶ ̶r̶e̶f̶e̶r̶r̶i̶n̶g̶ ̶t̶o̶ ̶i̶f̶ ̶a̶ ̶t̶e̶x̶t̶u̶r̶e̶ ̶h̶a̶s̶ ̶a̶ ̶d̶i̶f̶f̶e̶r̶e̶n̶t̶ ̶l̶i̶c̶e̶n̶s̶e̶ ̶f̶r̶o̶m̶ ̶C̶C̶0̶.̶ ̶B̶u̶t̶ ̶t̶h̶a̶t̶’̶s̶ ̶r̶e̶a̶l̶l̶y̶ ̶n̶o̶t̶ ̶p̶a̶r̶t̶ ̶o̶f̶ ̶t̶h̶e̶ ̶d̶i̶s̶c̶u̶s̶s̶i̶o̶n̶.̶

Wait sorry … I think I misinterpreted your post. You mean that if a texture is GPL the resulting picture also has to be GLP? I am really not so sure about that. Never thought about GPL in context of pictures, though.

But yeah - all of that that goes beyond this topic and ultimately I still agree that that Blender’s official plattform should use CC0 for that exact reason.

[Mikhail_Rachinskiy]

Is it not possible to disable auto check for updates?

[ideasman42]

Automatic updates are currently not supported, once they are it will be optional.

[redmser]

The documentation talks about using __package__ to avoid name conflicts for extension preferences. What about other places where name conflicts can happen? Mainly the names of new bpy.ops, new IDprops added to data blocks, as well as ids and class names for panels. Is there anything that can be recommended or done there, other than picking a unique enough name?

[Mikhail_Rachinskiy]

You prefix their ids with add-on/__package__ name.

[ideasman42]

This is indeed a weakness with the current method of name-spacing extensions, that it only works on a Python module level and doesn’t extend to handling naming collisions in other register-able types: operators/panels/menus/render-engines… etc.
While this could be supported, it’s not trivial and isn’t part of the planning right now.

[ValyArhal]

What exactly is the strictness on this two things?
https://developer.blender.org/docs/handbook/addons/guidelines/#style-recommendations

https://developer.blender.org/docs/handbook/addons/guidelines/#criteria-to-be-checked-before-evaluation

when we’re talking about external sites this kind of conventions are never upheld, but now this being an official platform the thing that bothers me is especially the styling sections, so many popular addons are not even remotely following this, does this mean there are going to be changes to be made, does it mean someone can become a maintainer and completely change style/rules the addon was made with before uploading it here?

with what is being stated in there is absolutely zero incentives to even consider this, especially the Consistency (the interface and functionality should try to match with the existing feel and conventions of Blender). thing, that’s just impossible for some addons, i’d have to personally have to spend more time on that to follow rules the users don’t care about rather than focusing on developing the actual addon

also what’s up with the ‘anyone can upload an extension without even notifying the developer’

it’s not a just don't upload it then situation when you include that someone else can upload them without even asking the developer behind it and now that developer has to upload it themselves to keep their own addon from being redistributed by a random person, no user is going to be able to make the distinction on whether it was from the original developer that made it or someone randomly uploading it leaving anything going wrong with the randomly redistributed addon on the original developer that had no hands in it

with a policy like that said mentality is out of the window, there is literally zero reason on why anyone would want to work on their addon if this is something that can happen
just because it’s gpl 3 for example, that should not mean the site just accepts addons from other peoples than the developer themselves, it should be rather that at maximum someone else would be assigned as the maintainer if the original developer is unable for any reason to maintain it or stopped development if it was already uploaded here

what if someone uploads a paid only addon? is that ok just because it’s gpl? this isn’t a licensing issue by any mean, rather, do you want developers to keep making essential addons or not? this is going to just drive off existing developers and stop new ones from wanting to make addons

little clarification en is not my first language, i imply the lack of definition for authored work not being respected with anyone can upload an extension

[Dangry]

I also feel like many of the guidelines are way too strict. Most popular addons do not follow many of the guidelines at all, and would require massive rewrites, not to mention the amount of time it will require to review each addon!

I think it should be vastly simplified and made less strict, otherwise, what is the point if none of the most popular and used addons can not even be added?