Addon loading failed with exception instead of the proper error #83133

New Issue

Rabit · 2020-11-28T00:09:34+01:00

Rabit commented

2020-11-28 00:09:34 +01:00

System Information
Operating system: MacOSX 11.0.1

Blender Version
Broken: at least since 2.80
Worked: none

Short description of error
If addon contains dots in the name - it will not be loaded and fail with unclear error:

So I think restriction of loading an addon with version in the addon dir name is a good thing, but there should be a clear error about that to allow the user to fix the issue.

Original issue is here: https://github.com/state-of-the-art/BlendNet/issues/123

Exact steps for others to reproduce the error
Name any addon with dots and try to load it

**System Information** Operating system: MacOSX 11.0.1 **Blender Version** Broken: at least since 2.80 Worked: none **Short description of error** If addon contains dots in the name - it will not be loaded and fail with unclear error: ![screenshot.png](https://archive.blender.org/developer/F9393412/screenshot.png) So I think restriction of loading an addon with version in the addon dir name is a good thing, but there should be a clear error about that to allow the user to fix the issue. Original issue is here: https://github.com/state-of-the-art/BlendNet/issues/123 **Exact steps for others to reproduce the error** Name any addon with dots and try to load it

Rabit commented

2020-11-28 00:09:34 +01:00

Added subscriber: @Rabit

blender-admin commented

2020-11-28 00:09:34 +01:00

#91509 was marked as duplicate of this issue

Germano Cavalcante commented

2020-12-01 14:34:54 +01:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2020-12-01 14:34:54 +01:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Germano Cavalcante commented

2020-12-01 14:34:54 +01:00

I'm not sure if I understood the problem.
Isn't "ModuleNotFoundError" already descriptive enough?

I'm not sure if I understood the problem. Isn't `"ModuleNotFoundError"` already descriptive enough?

Rabit commented

2020-12-01 21:46:22 +01:00

Unfortunately no - the users installs the addon archive, see the exception and don't understand why it's not found. It's not obvious - the addon is here (folder and stuff), but just contains dot in the name.

So for sure it's not enough for the user who just installed the addon from some archive. I believe there is a way to process it better than just show exception module not found - because it's here, just contains some wrong symbols in the name.

Unfortunately no - the users installs the addon archive, see the exception and don't understand why it's not found. It's not obvious - the addon is here (folder and stuff), but just contains dot in the name. So for sure it's not enough for the user who just installed the addon from some archive. I believe there is a way to process it better than just show exception module not found - because it's here, just contains some wrong symbols in the name.

Robert Guetzkow commented

2020-12-01 23:44:18 +01:00

Added subscriber: @rjg

Robert Guetzkow commented

2020-12-01 23:44:18 +01:00

Changed status from 'Needs User Info' to: 'Archived'

Robert Guetzkow closed this issue

2020-12-01 23:44:18 +01:00

Robert Guetzkow commented

2020-12-01 23:44:18 +01:00

@Rabit The developer of the add-on is responsible for naming it properly, just like they are responsible for following the correct Python syntax. If the add-on doesn't install this is obviously very frustrating for the user and it will not be obvious to them why this is the case. However, it is not the responsibility of the user to identify why this particular add-on doesn't work.

Ideally the add-on developer would test the add-on properly and ensure at the very least that it installs without error. Since in reality this isn't always the case, the user will likely have to complain to the add-on developer who is (hopefully) able to understand a stack trace or what a ModuleNotFoundError is. A more descriptive error message doesn't really help the user since they likely can't fix the problem themselves and still have to get the developer involved to fix the problem.

@Rabit The developer of the add-on is responsible for naming it properly, just like they are responsible for following the correct Python syntax. If the add-on doesn't install this is obviously very frustrating for the user and it will not be obvious to them why this is the case. However, it is not the responsibility of the user to identify why this particular add-on doesn't work. Ideally the add-on developer would test the add-on properly and ensure at the very least that it installs without error. Since in reality this isn't always the case, the user will likely have to complain to the add-on developer who is (hopefully) able to understand a stack trace or what a `ModuleNotFoundError` is. A more descriptive error message doesn't really help the user since they likely can't fix the problem themselves and still have to get the developer involved to fix the problem.

Robert Guetzkow commented

2020-12-01 23:49:25 +01:00

I think it is down to personal preferences if it would be better to have an error message that states "This add-on is broken and can't be activated" or it displays the stack trace. In the end the user still has to complain to the developers to get it fixed.

Rabit commented

2020-12-02 00:05:07 +01:00

So for example in my particular case - I did everything correctly, packed my great addon properly, but github also provides a way to download the sources of the release and the tags are attached to the repo name like "BlendNet-v0.5" (https:*github.com/state-of-the-art/BlendNet/issues/123#issuecomment-734960407). It's a different convo with github guys here: https:*github.community/t/control-prefix-of-the-release-source-code/145808 , but overall there is not much I can do if user by mistake clicks on this link and downloads the wrong artifact. Or even just to accidentally put dot in the name because he likes dots - doesn't matter.

So you saying basically "it's not our problem that addon names should not contain dots" - but for sure it's not an obvious thing for anyone. You have this rule, which is fine, but the message is not saying "I found the addon with incompatible name", it says weird "addon not found". It's not clear, it's not describing why it's happening - so from my point of view it's clearly misleading message.

From my developer position - I can't do much if the users for some reason put my addon in the wrong folder or made a mistake - but I want to get a good issue reports from them and I want them to see what's the real issue here. Or probably it's possible that the user will understand what's wrong and fix it on his own - there always a way for proper error messages ;) I'm just telling it's not always up to developer - users can do things and they should not be misleaded by the weird error message.

So for example in my particular case - I did everything correctly, packed my great addon properly, but github also provides a way to download the sources of the release and the tags are attached to the repo name like "BlendNet-v0.5" (https:*github.com/state-of-the-art/BlendNet/issues/123#issuecomment-734960407). It's a different convo with github guys here: https:*github.community/t/control-prefix-of-the-release-source-code/145808 , but overall there is not much I can do if user by mistake clicks on this link and downloads the wrong artifact. Or even just to accidentally put dot in the name because he likes dots - doesn't matter. So you saying basically "it's not our problem that addon names should not contain dots" - but for sure it's not an obvious thing for anyone. You have this rule, which is fine, but the message is not saying "I found the addon with incompatible name", it says weird "addon not found". It's not clear, it's not describing why it's happening - so from my point of view it's clearly misleading message. From my developer position - I can't do much if the users for some reason put my addon in the wrong folder or made a mistake - but I want to get a good issue reports from them and I want them to see what's the real issue here. Or probably it's possible that the user will understand what's wrong and fix it on his own - there always a way for proper error messages ;) I'm just telling it's not always up to developer - users can do things and they should not be misleaded by the weird error message.

Robert Guetzkow commented

2020-12-02 01:05:19 +01:00

Added subscriber: @mont29

Robert Guetzkow commented

2020-12-02 01:05:19 +01:00

This comment was removed by @rjg

*This comment was removed by @rjg*

Ankit Meel commented

2020-12-02 06:51:46 +01:00

Added subscriber: @ankitm

Ankit Meel commented

2020-12-02 06:51:46 +01:00

We could trim the addon folder name while installing the add-on after discarding everything after the first . in the name (excluding .zip).
And to prevent confusion, also warn users that a different name has been given to the add-on.

We could trim the addon folder name while installing the add-on after discarding everything after the first `.` in the name (excluding .zip). And to prevent confusion, also warn users that a different name has been given to the add-on.

Robert Guetzkow commented

2020-12-02 09:41:54 +01:00

@Rabit I retract my previous comment because you're right that this is a limitation Blender imposes, but it is based on Python's use of dot as a delimiter between modules. However, I still think that it is still the developers responsibility to test the files they release and even if this is partly an issue with GitHub this could be solved by telling the user which *.zip file to use in the install instructions. The filename of the .zip is irrelevant to the problem, it is the name of the top level folder that causes the issue in this report. Hence, it seems generally unlikely that users would break this themselves as they would have to rename the add-on's directory after a successful installation within Blender's directory where that add-on is located.

I will discuss this once more with the triaging team. While not used in constructing the path, there may be other characters that could be used in the directory name that are not valid module names in Python and/or are not valid names in Blender.

@Rabit I retract my previous comment because you're right that this is a limitation Blender imposes, but it is based on Python's use of dot as a delimiter between modules. However, I still think that it is still the developers responsibility to test the files they release and even if this is partly an issue with GitHub this could be solved by telling the user which *.zip file to use in the install instructions. The filename of the .zip is irrelevant to the problem, it is the name of the top level folder that causes the issue in this report. Hence, it seems generally unlikely that users would break this themselves as they would have to rename the add-on's directory after a successful installation within Blender's directory where that add-on is located. I will discuss this once more with the triaging team. While not used in constructing the path, there may be other characters that could be used in the directory name that are not valid module names in Python and/or are not valid names in Blender.

Bastien Montagne commented

2020-12-02 09:46:27 +01:00

Let's not complicate things when it is not needed shall we? Add-ons are in python, they are python modules, and in Python dot is used to separate modules from sub-modules or their content, it's like the (back)slash in OS file paths.

Do you put (back)slashes in your file names? No, because it's forbidden. Same with dots in python modules (directories) names. Developers of add-ons are expected to have that basic ground level of python knowledge and package their add-on accordingly.

Let's not complicate things when it is not needed shall we? Add-ons are in python, they are python modules, and in Python dot is used to separate modules from sub-modules or their content, it's like the (back)slash in OS file paths. Do you put (back)slashes in your file names? No, because it's forbidden. Same with dots in python modules (directories) names. Developers of add-ons are expected to have that basic ground level of python knowledge and package their add-on accordingly.

Rabit commented

2020-12-02 20:05:21 +01:00

@rjg I totally agree that addon developers should test their code and make sure it's working well - that's why BlendNet is used daily CI to ensure that the addon is working properly on 2.80, LTS and Latest Blender. And right now there is no issue in the addon itself, it's just the GitHub interface that posting additional files on the release page:

unfortunately those Source files contains folder with the tag suffix (like "BlendNet-v0.3.3" is auto generated by the GitHub) that is lead to the user confusion and overall this situation where the addon developer can do almost nothing. Of course I can change my tags to something like "v0_3_3" - but it looks like a tricky solution and not solving the other cases where user just want to use dots there.

For the user those limitations are not existing. They just want to unpack the addon and place it with the name they like (since it's a path-based user interface). They don't want to know if there is some python or not python limitations - for them it's "Addon is not working correctly". And I agree - it is, but if there is a little more information about "what exactly happened" and could allow the user of Blender to solve it and understand it more - that's an improvement of the Blender interface that will save tons of time on those additional actions and usability, not something that is useless. So simple "Addon folder name contains not allowed characters" - will say a lot and could be quickly checked.

Thank you

@rjg I totally agree that addon developers should test their code and make sure it's working well - that's why BlendNet is used daily CI to ensure that the addon is working properly on 2.80, LTS and Latest Blender. And right now there is no issue in the addon itself, it's just the GitHub interface that posting additional files on the release page: ![screenshot.png](https://archive.blender.org/developer/F9426334/screenshot.png) - unfortunately those Source files contains folder with the tag suffix (like "BlendNet-v0.3.3" is auto generated by the GitHub) that is lead to the user confusion and overall this situation where the addon developer can do almost nothing. Of course I can change my tags to something like "v0_3_3" - but it looks like a tricky solution and not solving the other cases where user just want to use dots there. For the user those limitations are not existing. They just want to unpack the addon and place it with the name they like (since it's a path-based user interface). They don't want to know if there is some python or not python limitations - for them it's "Addon is not working correctly". And I agree - it is, but if there is a little more information about "what exactly happened" and could allow the user of Blender to solve it and understand it more - that's an improvement of the Blender interface that will save tons of time on those additional actions and usability, not something that is useless. So simple "Addon folder name contains not allowed characters" - will say a lot and could be quickly checked. Thank you

Robert Guetzkow commented

2020-12-02 21:54:38 +01:00

@Rabit I've understood that GitHub causes the issue in your specific case. My point was more about the general responsibility an add-on developer has, since adding a check like this needs to be justified by a general necessity and usefulness. The reasons why we haven't simply added a check are:

The developer should provide adequate installation instructions so that users download the correct file and follow the right procedures.
Users should install their add-ons through the preferences (Edit > Preferences > Add-ons > Install). Thus, if they are using an add-on that was implemented, named and packaged properly, it should install and activate without issues.
There are many ways an add-on can be improperly implemented or distribute so that it fails to activate. If we were to add a check and dedicated error message for every mistake an add-on developer (or the platform that packages their add-on) could potentially make, then this would be a long list of tasks. Naturally, one can argue in favor of the check you have proposed and it is a reasonable proposal. However, we do have to draw the line somewhere with regards to the responsibility of the add-on developer and Blender checking for edge cases that may break the add-on activation. Where we draw the line is ultimately up to the core developers and development coordinators. @mont29 has already voiced his disapproval.
The message would only be marginally useful since a) users should not get in the situation where they are renaming add-on directories or files, b) the developer should be capable of understanding the stack trace that is currently provided. The case where a user would be incapable of fixing the problem with the current stack trace, but would suddenly be when the error message explains that dots are not permitted in the directory name, seems rather unlikely. Consider the following scenarios:
The user downloads an add-on and installs it through the user preferences. During activation the proposed error message is displayed. The user does not know where the add-ons are located, why the add-on they've attempted to install contains an invalid name and why they have to fix an error in the add-on. Most likely the improved error message doesn't replace the need for the developer to fix the issue.
The user manually copies an add-on into Blender's directory and then for some reason decides to rename the directory to a string that contains a dot. In this case the proposed error message would be more helpful. However, most likely the user is already tech-savvy enough to realize that Blender is not loading / finding the module with the current stack trace and that this is caused by them renaming it.

In summary, it is entirely possible to write a simple patch for this. However, from my current understanding, it would likely not be accepted. The reason is that it's a minor edge case that most users will never see. If they do see it, it doesn't cause any particular harm to Blender's installation and for a majority of these rare cases it's the add-on developers responsibility to handle this because either they have distributed a broken add-on or their install instructions weren't clear enough.

The ticket is closed and based on @mont29 decision it will stay closed.

@Rabit I've understood that GitHub causes the issue in your specific case. My point was more about the general responsibility an add-on developer has, since adding a check like this needs to be justified by a general necessity and usefulness. The reasons why we haven't simply added a check are: - The developer should provide adequate installation instructions so that users download the correct file and follow the right procedures. - Users should install their add-ons through the preferences (*Edit > Preferences > Add-ons > Install*). Thus, if they are using an add-on that was implemented, named and packaged properly, it should install and activate without issues. - There are many ways an add-on can be improperly implemented or distribute so that it fails to activate. If we were to add a check and dedicated error message for every mistake an add-on developer (or the platform that packages their add-on) could potentially make, then this would be a long list of tasks. Naturally, one can argue in favor of the check you have proposed and it *is* a reasonable proposal. However, we do have to draw the line somewhere with regards to the responsibility of the add-on developer and Blender checking for edge cases that may break the add-on activation. Where we draw the line is ultimately up to the core developers and development coordinators. @mont29 has already voiced his disapproval. - The message would only be marginally useful since a) users should not get in the situation where they are renaming add-on directories or files, b) the developer should be capable of understanding the stack trace that is currently provided. The case where a user would be incapable of fixing the problem with the current stack trace, but would suddenly be when the error message explains that dots are not permitted in the directory name, seems rather unlikely. Consider the following scenarios: - The user downloads an add-on and installs it through the user preferences. During activation the proposed error message is displayed. The user does not know where the add-ons are located, why the add-on they've attempted to install contains an invalid name and why they have to fix an error in the add-on. Most likely the improved error message doesn't replace the need for the developer to fix the issue. - The user manually copies an add-on into Blender's directory and then for some reason decides to rename the directory to a string that contains a dot. In this case the proposed error message would be more helpful. However, most likely the user is already tech-savvy enough to realize that Blender is not loading / finding the module with the current stack trace and that this is caused by them renaming it. In summary, it is entirely possible to write a simple patch for this. However, from my current understanding, it would likely not be accepted. The reason is that it's a minor edge case that most users will never see. If they do see it, it doesn't cause any particular harm to Blender's installation and for a majority of these rare cases it's the add-on developers responsibility to handle this because either they have distributed a broken add-on or their install instructions weren't clear enough. The ticket is closed and based on @mont29 decision it will stay closed.

Rabit commented

2020-12-03 00:19:23 +01:00

@rjg I understand the complexity of catching every issue possible - it's not a great for sure. But if the error generates the message where instead of the module directory "BlendNet-v0.3.3" we have part of it "BlendNet-v0" - it looks weird. For sure it's a limitation of the python, but who need to be aware of it and find out what's wrong - Blender or the User?

If there is a limitation and the installation logic passed such addon to be installed - than it's is correct, right? For example it's checking bl_info structure in the addon and reads name, version and description from it? User see - the addon was properly installed, but can't be enabled for some weird reason. If User installed it manually - he can connect the points and see that part of the Addon name is missed, but if he used the builtin installer - hi don't even know from the error what was wrong. So why installation process is not checking the restrictions for the addon directory name to be usable during enabling?

For sure it's an additional check, but I think it's worth it to include in the regular Addon install check suite. So if it's just matter of who will prepare a patch - I'm good to do that and put some efforts to push it in master branch, but if there is a general misunderstanding of what is the issue about - there is probably no use, and it's making me sad...

Thank you

@rjg I understand the complexity of catching every issue possible - it's not a great for sure. But if the error generates the message where instead of the module directory "BlendNet-v0.3.3" we have part of it "BlendNet-v0" - it looks weird. For sure it's a limitation of the python, but who need to be aware of it and find out what's wrong - Blender or the User? If there is a limitation and the installation logic passed such addon to be installed - than it's is correct, right? For example it's checking `bl_info` structure in the addon and reads name, version and description from it? User see - the addon was properly installed, but can't be enabled for some weird reason. If User installed it manually - he can connect the points and see that part of the Addon name is missed, but if he used the builtin installer - hi don't even know from the error what was wrong. So why installation process is not checking the restrictions for the addon directory name to be usable during enabling? For sure it's an additional check, but I think it's worth it to include in the regular Addon install check suite. So if it's just matter of who will prepare a patch - I'm good to do that and put some efforts to push it in master branch, but if there is a general misunderstanding of what is the issue about - there is probably no use, and it's making me sad... Thank you

Robert Guetzkow commented

2021-09-19 00:36:42 +02:00

Added subscriber: @ManBlender

Pratik Borhade referenced this issue

2023-03-13 06:15:19 +01:00

Addons files with a dot in the name can't get Ednabled #105679

Pratik Borhade referenced this issue

2023-04-03 05:47:21 +02:00

Loading a plugin with dots in the zip name fails in Blender 3.x #106408

Sign in to join this conversation.