@Ankit Meel (ankitm) Thanks for merging my report. I was aware of this one here, but thought a more generalized phrasing would draw more attention to, what looks like a very pressing issue.
If you think it makes sense, maybe rename this one here to reflect that?
Anyway, thanks for the fix, hope it gets committed quickly!

It does not seem to happen when setting custom normals using Blender's native tools, for instance using mesh.set_normals_from_faces()
But it will happen when doing it from python. Here's a sample implementation for setting custom normals from the active face:

Thank you!

Thanks for pointing that out, much appreciated!

@Robert Guetzkow (rjg) Just wanted to comment as well, in case this is in response to Eric, whom I've sent here. His crashes are related to adding/removing ID data using layout.template_icon_view and so changing ID data from enum update callbacks. This is still unresolved, yet my reports about it were all closed.
I was told conflicting information: 1. Don't change ID data from update callbacks and don't run operators from them, 2. If you change ID data use operators. Following this advice means the template_icon_view layout element has become useless for its most popular use case: adding external assets. Since Blender is crashing when undoing after such an operation, it also risks data loss for a huge amount of Blender users.

Read all of this, still don't have a working solution to prevent Blender crashing when appending using the layout.template_icon_view() as the interface (followed by undo)

Thumbnails not loading at all is not a known problem to me.

Understood, thanks for clarifying!

Since this is crashing Blender, and since it never was was problem before 2.83, I feel like this warants more than "don't do this".

Understood, thanks!

@Robert Guetzkow (rjg) Shouldn't this be BF Blender (2.90) too? It's confirmed two times to crash 2.90.

@Philipp Oeser (lichtwerk) I'm not sure either so I appreciate the input. The addon throws and exception when rendering in the compositor, the fix is easy and done already. So why not bring it to LTS, considering it will be in use for the next 2+ years.

Hi @Campbell Barton (campbellbarton), can you take a look at this please?

Look, you have your addon supplied with Blender. You are responsible for it.

Right now, Blender 2.83 is the latest stable release. Please consider getting this into 2.83 as well. 2.83 is the long time release and will be supported for the next 2 years. Since your addon is officially supplied with Blender, and since this is just a fix, not a new feature, it should go into the next bugfix release, so 2.83.6.

This bug is not in fact fixed in 2.90 yet. It was marked as a duplicate of T77298 which seems to be fixed, but its only baking diffuse. Normal baking is still broken, you can check the sample file here or set the baker to Normal in T77298

I've noticed that Blender 2.90, doesn't seem to have this problem anymore, yet Blender 2.83.5 still has. So can we get this fix into 2.83 LTS too? Also, why hasn't the version changed at all?

I see, thanks!

In T78197#987568, @Yevgeny Makarov (jenkm) wrote:

You need to use Click instead of Press.

In T79376#987566, @Yevgeny Makarov (jenkm) wrote:

These NORTH, SOUTH, ... these are for TWEAK events.

Trackpad events always event.val = KM_NOTHING.
Try to look at event.x, event.y, event.prevx, event.prevy.

There is no bug here.

Is 3ada1949f863 not going to be a part of 2.83.1 (or future bugfix releases)?

It does!

In T77768#956604, @Campbell Barton (campbellbarton) wrote:

This usage from Python makes sense to support.

You can now use: bpy.data.libraries.write(path, datablocks, path_remap='RELATIVE_ALL') for previous behavior, other options are ABSOLUTE/RELATIVE/NONE

Thing is I only export some images in the file, theses ops would make all paths relative/absolute, which is overkill, as I can easily have hundreds of images, but save out only a handful.

It's a bit cumbersome to first collect all images in the scene that is to be saved, then change the paths, then save out the scene, then change the paths back to what they were before (absolute).
So I really liked the way it worked before and wish there was an option that would restore that behavior. It was a lot simpler and just worked.

Thanks for the info!

Why not at least prevent the error using the ignore_errors arg?

Thanks for clearing that up.

This is consistent behavior with the error message as well as with what you are allowed to do manually.

This is working as intended, pass --python-use-system-env for previous behavior.

I can understand that, but honestly, this is a terrible thing to ask of addon users.

It's a worthy cause for sure :) Good luck with your thesis and thanks for your input!

"Defaulting to user installation because normal site-packages is not writeable"

As it should be to be honest.

I'm ready to close this but can somebody offer a suggestion what addons relying on non-supplied modules should do?
I can just append the path to sys.path when registering of course. @Brecht Van Lommel (brecht)?

Apparently, its intentional? https://developer.blender.org/rBS79a58eef059ffc3f12d11bd68938cfb1b4cd2462