Experimental: Feature sets

Check against existing requests

[X] I have checked existing feature requests, and my idea is different

Describe the context

Propose an experiment feature for developers or Python users to extend, change MCprep without touching the main code, feature sets. It isn't a new concept, in the code for #260 the word "feature set" existed there and the experimental flag doesn't have much use also.

Why? Can you just add it directly and have it a fork, a branch?

An (external) feature set can be as zip to install to main MCprep keep that feature seperately and anyone want to install or disable. Similar to addon when it disabled or uninstall the normal functionality of MCprep will be back to normal, unregister that feature set. And the experimental for main MCprep one are default feature sets

What else can it be?

A way to keep feature versioning along side with Blender version.

Example: Weather Particle Effect as geo nodes only 3.0+, being a default feature set. if a user in 2.93 below then it is disabled.

Python user?

Yes, below like datapack it can be a way for someone not the main MCprep developers change or add more functionality along side with MCprep.

I might address this too since this is experimental so they need to be well aware of what they are doing. Something similiar before like #329 so it is maybe better to label this as "developer tool"

So that mean very features in current MCprep change to default feature sets?

NO . It is a way to extend override. This is good for small change that can be toggle on and off, like between old UI and new UI change. OR feature that change massively experimental or unstable to use. Big code, specific Blender versions can only use it.

How do you imagine your feature works?

It would be #260 making feature sets, a per feature rather an all toggle. Similiar to what Datapack in Minecraft in snapshot builds: how_to_enable_features_java2 Snapshot experimental through datapack

A UIList in a preferences tab only display with experimetal mode on. A UIList using a CollectionProperty with enabled BoolProperty.
Adding, installing an external feature set zip import (registering it)
Remove feature set (unregister, not enable)
Displaying the "mcprep_info" like "bl_info" of an addon. Blender version, author, links,..

What existing workaround (or closest thing to a workaround) do you have today (within Blender, MCprep, or any software)? If there is no workaround, explain why you feel this way.

An addon that have somthing similiar is Rigify. Rigify have other feature sets can be install in have extra rigs or functionalities those may change the UI.

MCprep already does have the concept of feature sets:

I think however this could be moved into its own panel and made simlar to Blender's feature sets:

What else can it be?

A way to keep feature versioning along side with Blender version.

Example: Weather Particle Effect as geo nodes only 3.0+, being a default feature set. if a user in 2.93 below then it is disabled.

We already do this through bv30 and min_bv, nothing about that would change with feature sets.

Python user?

Yes, below like datapack it can be a way for someone not the main MCprep developers change or add more functionality along side with MCprep.

I might address this too since this is experimental so they need to be well aware of what they are doing. Something similiar before like https://github.com/Moo-Ack-Productions/MCprep/issues/329 so it is maybe better to label this as "developer tool"

Let me repeat what I've said on that regarding that (this comment is on the GitHub Issue you linked as well):

We MCprep maintainers have a responsibility in keeping users' systems safe. If we make the Prepping API too easy to enable and users suffer as a result, I personally believe the blame would lie on us as we could have made this far harder to exploit. ... "Other addons and programs don't care" Cause either their userbases aren't full of naive 12 year olds that don't understand basic computer literacy (no offense to our usebase, but it has to be said) or they have their own scripting languages where doing messing up the system is impossible, and we're not going to write our own scripting language (that would be slow, and unmaintainable; I've written many compilers and interpreters, and it's not something most developers will grasp) ... "What about a sandbox?" The only proper way would be a process sandbox, which Blender does not come with. We can't make a sandbox at the Python level cause that's impossible; that was learned with pysandbox:

I now agree that putting a sandbox in CPython is the wrong design. There are too many ways to escape the untrusted namespace using the various introspection features of the Python language.

The Python language is weird in that we can do whatever to objects. Heck, we already do this for 2.7x support. The downside is that it makes sandboxing at the language damn near impossible. Pysandbox was at the interpreter level and it stilled failed, how badly would a sandbox implemented in Python fail?

Focus on this statement:

If we make the Prepping API too easy to enable and users suffer as a result, I personally believe the blame would lie on us as we could have made this far harder to exploit.

^ Are user defined feature sets really worth it when the risk is losing our credibility in the eyes of our users?

Any program that executes arbitrary, user written code needs to have some serious defenses. Chromium isolates the memory of each opened tab, the WebAssembly Spec defines sandboxing, Docker Containers are isolated, so you can't impact the main system. As stated above, we can't do any of that in MCprep simply because of the language itself. I would love to add the ability for user defined feature sets, but we can't be blinded by a want for a feature if said feature could compromise security. I don't say this because I'm paranoid, I say this because history has shown time and time (all separate links) again that security is not something to take lightly.

However, I will allow user defined feature sets to be merged if and only if it can be done securely (keep in mind, I'm the type of person to sandbox my browser further at the OS level with some extremely restrictive settings, so I have a pretty high bar for security). However, I'd rather make feature sets based on PRs open here, so at least it's been vetted.

I think however this could be moved into its own panel and made simlar to Blender's feature sets

That is the Blender preferences window and this is related to one addon so. So of course that UI List panel is in the addon preferences. Inject an addon preferences there make no sense right?

We already do this through bv30 and min_bv, nothing about that would change with feature sets.

Yes we already use bv30 and min_bv already. That think as it, not just one side. if someone in 2.8 trying to turn on a feature set raise an error log with detail why or don't turn on that feature set. Someone in 3.0 can turn on this feature set but can also turning off (if it is enable by default) and make it like that 2.8 person. And further if someone upgrade the weather effects using 3.6 simulation nodes through an (external) feature set that would be nicely management. Again, that would be reading through "bl_info"/"mcprep_info" ["version"] and min_bv that version value.

Let me repeat what I've said on that regarding that (this comment is on the GitHub Issue you linked as well)...

I'm expecting that 😅 That is why I introduced it with "default" feature sets in that, it would be a place to manage features afterall. https://discord.com/channels/737871405349339232/737871405999456318/1146314860523692082

For the "external" zip part that one could be hold on for that reason (or maybe atleast not expose the operator in the interface, adding the folder manually through the %appdata% way)

However, I'd rather make feature sets based on PRs open here, so at least it's been vetted.

Yes that is still important, but again I'm not sure about certain big code feature that isn't mostly a feature. It is like a feature that has a library, keeping the code seperate in an experimental system for users those want to install and try it then while PR stage would be the way. Is that familiar yet?

That is the Blender preferences window and this is related to one addon so. So of course that UI List panel is in the addon preferences. Inject an addon preferences there make no sense right?

We're not going to inject preferences there, I'm just saying MCprep could have a section for features in preferences like Blender's.

if someone in 2.8 trying to turn on a feature set raise an error log with detail why or don't turn on that feature set. Someone in 3.0 can turn on this feature set but can also turning off (if it is enable by default) and make it like that 2.8 person. And further if someone upgrade the weather effects using 3.6 simulation nodes through an (external) feature set that would be nicely management. Again, that would be reading through "bl_info"/"mcprep_info" ["version"] and min_bv that version value.

I think this is really a non-issue. Version-locked behavior falls under 2 catagories:

No alternative, but behavior remains identical. The OBJ importer falls under this
Alternative behavior alongside version locked features. This is what the effects spawner does

As long as we stick by those guidelines, it doesn't make sense to have feature sets for those things.

For the "external" zip part that one could be hold on for that reason (or maybe atleast not expose the operator in the interface, adding the folder manually through the %appdata% way)

Manual installation is not enough of a safeguard, look at Minecraft mods and the Fractureiser incident (honestly I should have mentioned this earlier). It didn't matter how you installed mods, all that is needed is a tainted file and trust. Again, our userbase is mostly naive 12 years olds, they're not going to be able to tell that something is off. Doesn't matter how complex you make installation, people will still follow instructions from some random person online.

As an aside, there was one safeguard for Linux Minecraft players (should they choose to use it) and that was Flatpak Minecraft launchers (as Flatpak is sandboxed). It was found that well designed Flatpak launchers like Prism Launcher were able to both prevent the malware from running and destroyed it on a sandbox restart. Just wanted to point out the importance of good security and what level of security I'm expecting if we want to run arbitrary, user defined code 😉.

~~And before you ask, Flatpak is Linux exclusive, it's not a workaround we can use for MCprep.~~

Yes that is still important, but again I'm not sure about certain big code feature that isn't mostly a feature. It is like a feature that has a library, keeping the code seperate in an experimental system for users those want to install and try it then while PR stage would be the way. Is that familiar yet?

As far as I know, that's what the Blender Foundation does, and it clearly works. It's not a bad idea, and all new features have to be made as pull requests anyway. Plus we could add a "alpha" set of releases to our new development cycle system, before we enter the stage of release candidates (which are mostly to iron out bugs).

Moo-Ack-Productions / MCprep