ImportError: No module named 'svrx' and others about sverchok HOT 22 CLOSED

The add on right now needs to be in folder called svrx. I created a symlink from my add-on directory to my git repo.

I wanted to avoid a hack like we did in Sverchok.
It is on of the unsolved issues.

# monkey patch the sverchok name, I am sure there is a better way to do this.

if __name__ != "sverchok":
    sys.modules["sverchok"] = sys.modules[__name__]

from sverchok.

The idea being that there would be a file download which has the correct name instead of sverchok-master that most people that use sverchok probably uses avoid such trickery.

But maybe I am overly worried about a quite small detail

from sverchok.

Btw how do you symlink on windows? Want to play with my new work laptop

from sverchok.

I don't think that's a terrible hack btw. I think zero users have complained about anything related to it.

symlink, you've probably figured out by now :)
I use
mklink /D destination_path origin_path

from sverchok.

you do need to open cmd prompt with admin privileges tho..

from sverchok.

ok cloned and symlinked as svrx, new error..

  File "2.78\scripts\modules\addon_utils.py", line 330, in enable
    mod = __import__(module_name)
  File "svrx\__init__.py", line 70, in <module>
    imported_modules = import_submodules(__name__)
  File "svrx\__init__.py", line 66, in import_submodules
    results.update(import_submodules(full_name))
  File "svrx\__init__.py", line 66, in import_submodules
    results.update(import_submodules(full_name))
  File "svrx\__init__.py", line 64, in import_submodules
    results[full_name] = importlib.import_module(full_name)
  File "2.78\python\lib\importlib\__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "svrx\nodes\generator\circle.py", line 14, in <module>
    List[Faces]
  File "svrx\nodes\node_base.py", line 230, in real_node_func
    get_signature(func)
  File "svrx\nodes\node_base.py", line 186, in get_signature
    s_type, level = parse_type(s_type)
  File "svrx\nodes\node_base.py", line 200, in parse_type
    return s_type.__parameters__[0], 1
IndexError: tuple index out of range

from sverchok.

s_type.__parameters__ appears to be an empty tuple when that IndexError is spat out.

from sverchok.

I will put the old fix in. That error is strange, I was thinking I would have to remove typing.List anyway but this is strange.

Test the following in the python prompt?

>>> from typing import List
>>> List[int].__parameters__
(<class 'int'>,)

I will have make my own meta class that does what I want I guess, for now all List[type] -> [type]

from sverchok.

>>> from typing import List
>>> List[int].__parameters__
()

from sverchok.

But that also requires some changes in other places..

from sverchok.

that's python 3.5.2 locally too.. same thing

from sverchok.

It is a new module, prone to change, I have 3.5.1. Dropping that for now.

Only really used to look nice in a hackish way..

from sverchok.

@zeffii
Please test now

from sverchok.

Catching this early is very helpful, thanks for testing

from sverchok.

roger that, yeah loads up fine. add SvRxNodeMeshOut to the menu or something, i couldn't find it had to add via code to layout.

from sverchok.

yeah it is a logical lapse from me. Needs to be fixed.

from sverchok.

there's no real reason why an input socket can't accept more than 1 link , right?

else we can have bm sockets, that accept either a real bm link or (verts+edges/faces) and get converted into bm (warning to the user that this has some overhead.. but whatever)

from sverchok.

alternatively, if a verts socket is linked into a bm socket, svrx can spawn a converter node..

from sverchok.

getting a few bm nodes done would quickly make exploration more fun

from sverchok.

I think we should have a mesh socket going into the outputs nodes, for now mostly testing the base system.

from sverchok.

it imports so closing for now, the menu is on my radar

from sverchok.

good

from sverchok.