Install from sverchok and Update dependencies

[vicdoval]

Two proposals:

1 A feature to Install Sverchok-Extra from Sverchok Prefences panel (one button to install and maybe another to go to the sv-extra preferences)

2 An option "check for updates" and update (for add-on and for dependencies) from the Sverchok-extra panel

[vicdoval]

I was thinking that even better would be to integrate sverchok-extra in sverchok... we have so much goodies (like travis, check for updates, search utils...) and create a way to avoid loading the nodes the user cant use (for a lack of dependencies)

[portnov]

Maybe... the idea was that installing Sverchok-Extra by itself is not a problem anyway, installing depenencies is much bigger problem. @zeffii ?

[zeffii]

I find it difficult to be very passionate about ecosystem of installing third party stuff. It's a lot of work and it might be an endless support ticket generator. We've talked about this dependency issues on-and-off for years.

what I would welcome is a section in regular Sverchok preferences, "Dependencies", where you tell sverchok to "auto detect current python directory " and from there it might detect some of the common dependencies (SciPy..whatever we can hardcode a list, which can be appended to by the user at runtime) . Each found dependency would test automatically and show a ✔️ or ❌ and if X then tooltip or dump to sverchok.log why it failed.

it might be necessary to include dependencies requirements in the .py file like

#! require scipy
#! require voronoi_lib 

# This file is part of project Sverchok. It's copyrighted by the contributors
# recorded in the version control history of the file, available from
# its original location https://github.com/nortikin/sverchok/commit/master
#  
# SPDX-License-Identifier: GPL3
# License-Filename: LICENSE

and the loader would skip over those files, and thus not even register them, if they are not fulfilled

[Durman]

What will be if somebody will open an existing file (or gist) with a node which is not even registered?

[zeffii]

a dummy node.

[zeffii]

we can add a feature to the on_save event handler, that writes to bpy.data.texts['sv_dependcies.txt'] This could be read, and parsed before the node tree processes anything. My suspicion is that it's a good idea to have that information serializable and human readable.

[portnov]

@zeffii It's not quite clear for me: what for one would need a list of available dependencies in Sverchok preferences, if he is not able to use them (without extra addon)?

[zeffii]

hmmm. chicken and egg problem

[vicdoval]

the idea would be finally not needing the extra add-on wouldn't it?

[zeffii]

yep

[vicdoval]

How do you feel about that @portnov no more extra- categories, being able to find the nodes in the search menu...

[portnov]

@vicdoval You mean to put Sverchok-Extra's nodes into main Sverchok categories? I'm fine with it, current solution just seemed technically easier to implement.

@zeffii So you're not against merging Sverchok-Extra with it's "sort-of-dependency-manager" into main Sverchok?

[zeffii]

@portnov nope, not against it. i will be actively ignoring tracker issues about 3rd party stuff tho :)

[portnov]

The question of support is actually an important one. It will be hard to explain users, why are we actively supporting one part of the addon and not supporting another part.

So, I'd suggest to make a division: what we will support will go to Sverchok; what we will not be able to support so well, will go to Sverchok-Extra.

The question is, how to make this division?

One approach is as follows. There are two kinds of "3rdparty" nodes: A) those which rely on some functions in another library for their "domain-related" (3d graphics / design / etc) semantics, and do just a call to that library to do the whole work. A clear example of this category is @vicdoval 's LadyBug nodes. B) those which use functions from another library just to do some not-domain-related calculations, but have all domain-specific logic in the node. For example, some of scipy-based nodes call for root-finding or minimization functions from scipy; scipy does not know what is "3d graphics", or even what "surface" is - it knows only that it was given a function and asked to find it's minimum. The node applies that to, for example, find the nearest point on the surface.

We most probably can not properly support nodes from category A, even if we wanted to. But with nodes with category B — why not? 3rd-party logic is just an utility for them. We always can redirect problems into, for example, scipy's bugtracker if we think the problem is within scipy - but such cases will be rare, just because scipy is much better tested than Sverchok is.

Another approach is related to the documentation. Will we write documentation for the nodes? In Sverchok we have good tradition of writing documentation. In Sverchok-Extra, currently there is no documentation at all. For nodes of category A), we probably can not write proper documentation: I think all what can @vicdoval write about LadyBug nodes is please refer to LadyBug documentation to understand what these nodes are exactly doing. For nodes of category B, we can write documentation, because we implement all the domain-specific logic (the only one that actually must be described in user documentation). The node finds a point on the surface, which is the closest to the provided point. Note: this node uses scipy library.

So, the suggestion is: let's move nodes, for which we 1) perfectly understand what they are doing, since we wrote the domain-specific logic, 2) will write documentation, and 3) we are willing to support them - to Sverchok. Nodes for which we either 1) rely on the 3rd party library to do "the whole thing", or 2) are not willing to write documentation, or 3) are not willing to support them - remain in Sverchok-Extra.

okay?

[vicdoval]

The only problem I see of keeping the extra addon is that then there are two repositories to maintain and update. Also to encourage other developers to code for sv-extra we have to ensure:

• this is fixed #17 (that i think it may be related to the order the two addons are loaded),

• the chance to appear in the search-menu

• the possibility to add examples

• a Travis check that loads blender installs both addons and performs the regular Sv tests and maybe some sv-extra ones

• (optionally) the chance to add the exta nodes to the existing categories

About the documentation: I believe all published nodes should have a documentation (even if it is only a line and a link). Is always a bit tedious but a lack of docs gives a permanent "alpha" state image to the add-on.

As a last point i think Sv-extra is more a a sverchok add-on than a blender addon so it would be more clear if its preferences where inside sverchok preferences and even its files in a folder inside the sverchok folder

All of this thoughts lead me to think that it was easier to migrate everything inside regular Sverchok, but I understand the question of "support" and also I see if we could find a clean solution for sverchok-extra maybe other devs may feel motivated to code for it or to write their own sverchok extension with their own issue tracker

[ranska]

About the documentation: I believe all published nodes should have a documentation (even if it is only a line and a link). Is always a bit tedious but a lack of docs gives a permanent "alpha" state image to the add-on.

About the documentation. Will PR for documentation be accepted? Even if they are only very light at the start? I think the best for learning it will be to try to document but some confirmation on a documentation PR will be the best way to do it. I'm very interested by nurbs surface so I'm ready to do some try.

[portnov]

Will PR for documentation be accepted?

Yes, off course! :)