Handling direct import errors in add parser

[ShahriyarR]

Change Summary

Description

The failed imports at feature and module levels should be handled properly

Fixes #24

Type of change

Please delete options that are not relevant.

• [X] Bug fix (non-breaking change which fixes an issue)

Checklist:

• [x] My code follows the style guidelines of this project
• [x] I have performed a self-review of my own code
• [x] I have commented my code, particularly in hard-to-understand areas
• [x] I have made corresponding changes to the documentation
• [x] My changes generate no new warnings
• [x] I have added tests that prove my fix is effective or that my feature works
• [x] New and existing unit tests pass locally with my changes

[asterkin]

The issue is #30 but the branch called issue24 (I used another convention of DYNACLI#, we'd better stick to a common convention, whatever community thinks is right).

[ShahriyarR]

The issue is #30 but the branch called issue24 (I used another convention of DYNACLI#, we'd better stick to a common convention, whatever community thinks is right).

The issue ID is not 30, the PR ID is 30, but the actual issue ID is 24, that is why the branch name is issue_24. There are many conventions about branch naming, what I can propose let's name our branches as describe here: https://idiv-biodiversity.github.io/git-knowledge-base/branch-naming-conventions.html or here: https://deepsource.io/blog/git-branch-naming-conventions/

I did not encounter some naming as DYNACLI_# before. So as a result we could name as: 24-add-module-shortcut or issue-24

[ShahriyarR]

@asterkin please take another look

[ShahriyarR]

@asterkin PTAL. As root package imports also gave ModuleNotFoundError - it is impossible to differentiate if it was root package level import error or inner level.

[ShahriyarR]

@asterkin PTAL