Is having separate libraries for dynamo and grasshopper is the best approach for development?

[ladybug-tools]

Is having separate libraries for dynamo and grasshopper is the best approach for development?

[sariths]

@mostaphaRoudsari ,

I am glad that you are bringing this up right now. I guess the traditional way to do duck-typing is through classes, inheritance and polymorphism (or class reimplementation where we don't want any inheritance).

I think the issue with doing this in the Honeybee,Gh,Dynamo scenario is that , we'd have to at least have the modules with same file names (as in core) in each of the libraries and then do a from foo import * kind of thing.

I tried a different way of doing this which involves the least footprint, but perhaps isn't pythonic. In my example, there is no code duplication whatsoever (well except in the init.py) of each package. The code below checks for implementations of modules in the local package and fetches them from the core library if it cannot find it.

from pkgutil import iter_modules
import os.path
import core

coreFile = os.path.dirname(core.__file__)
coreScripts = [name for x,name,y in iter_modules([coreFile])]

curModule = os.path.dirname(__file__)
curScripts = [name for x,name,y in iter_modules([curModule])]

_all_ = list(set(coreScripts+curScripts))

for moduleName in _all_:
    if moduleName not in curScripts:
        exec('from core import {0}'.format(moduleName))
    else:
        exec("import {0}".format(moduleName))

Now when a client interacts with the library he will be interacting dynamo,grasshopper or rhino and not core.

import dynamo
import grasshopper
import rhino


for modNames in (dynamo,grasshopper,rhino):
    print("The library being tested is: %s"%modNames.__name__)
    print(modNames.printBye.testBye)
    print(modNames.printHello.testHello)
    print("~*~"*10)

...results in....

The library being tested is: dynamo
testBye inside dynamo
testHello inside dynamo
~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~
The library being tested is: grasshopper
testBye inside core
testHello inside core
~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~
The library being tested is: rhino
Test Inside Rhino
testHello inside core
~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~

If you look at the screenshot right in the beginning, you'd notice that the library for grasshopper does not actually implement printBye and printHello. So, the init script fetches it from the core library. In contrast, dynamo implements both locally so both the values are fetched from the dynamo library.

I just tried this as a way to explore if such a thing is feasible in python, I don't know if this is actually a good way to approach this problem. My scripts are here : https://www.dropbox.com/s/1m50i3jkpoc3ppx/demo.zip?dl=0

[mostaphaRoudsari]

Hi @sariths I wrote answer to this but then I closed the page before sending it. :|

In short you're addressing a different issue which is a fair one. My main concern is this issue is the structure of the code itself for the development while your suggestion is on the client side and how the import the modules.

I have some comments on your approach but let me post them after I do more research. I'm very happy that we're getting to all this issues now before we get more developers involved.

[sariths]

@mostaphaRoudsari Aha...okay, I think I get what you intended. Well, with my own scripts, I try to reuse code (in an Object Oriented way) as much as possible. I am not sure how much of that will be possible with Honeybee-core as I have no idea about the dyanmo side of things will pan out in the future.

[chriswmackey]

@mostaphaRoudsari and @sariths ,

I have been thinking about this and I am also realizing that having 8 code repos (2 LB/HB x (3 geometry interfaces+1 core library)) goes against the notion that we are all working on the same code. I agree that a duck typing situation is probably best as long as we can implement it in a consistent manner that runs a check for the geometry interface at the top of the script. The ability to set "raise not implemented" functions is also critical to help out developers who are only versed in 1 or 2 of the geometry interfaces and don't know how to code for the others.

I get the sense that having multiple people work in the same file will encourage more collaboration than the alternative, bringing together people who are each well-versed in the different 3D libraries. It will also encourage developers to be wary of the different interfaces that they are coding for, even if they do not know the libraries for all 3 interfaces.

We should also keep in mind that this whole new Ladybug + Honeybee API will establish another level of coders who are just using the API and working in their own stuff on top of this. So I find it justifiable to have the development of the API itself become more difficult since it is possible to develop with a Ladybug API in a manner that is really fast and easy.

Very glad to be having this discussion now,
-Chris

[mostaphaRoudsari]

I have added a config.py file which returns the platform that the code is executing form. This is the first step to be able to implement the several geometry libraries in the same file. I will update this discussion once I have a prototype so you can both comment on the code.

[chriswmackey]

Awesome! Glad to hear it.

[mostaphaRoudsari]

@sariths and @chriswmackey! I'm happy to report back that I have the prototype of implementing all the geometry operations under the same library ready, and there are 3 example files for Grasshopper, Revit and Dynamo which are using the same library honeybee-geasshopper and the same API calls.

Here is how it happens. You can use config library to get the platform that the code is executed from. For now the platforms are grasshopper, dynamo, revit and the command line.

config also imports the libraries based on the geometrical platform. For instance if you're running a script from Grasshopper then you can access Rhino and Grasshopper under config.libs.Rhino and config.libs.Grasshopper. For Dynamo it is config.libs.Dynamo and config.libs.DesignScript.

Then the approach is pretty much what @sariths mentioned above.

In some cases the function only works in one of the platforms which gives an error if the user is using it from the wrong platform.

In other cases the definition is small enough to implement it both under the same function by checking the platform or duck-typing.

Finally, in some cases we need to write separate [private] functions for different platforms. These functions can be collected in different files and be called from geometryoperation.py.

So here are the questions moving forward:
1. Is it a better approach than what we had before?
My personal opinion is yes. The main issue that I can see is that not many people will know about both platforms and having the code in the same place can be hard to manage but I think we can control that by a clear file structure and also clean documentation. I also see this as an opportunity for developers to learn both API's from each other.

2. If we agree on 1 and keep the development under the same library what should be the name of it?
Now that we won't have honeybee-grasshopper and honeybee-dynamo what should we call this library? Here are a couple of options.

library with geometry	core library
queenbee	honeybee
honeybee	bee
xbee	honeybee

Let me know your thoughts.

[sariths]

@mostaphaRoudsari +1 for I also see this as an opportunity for developers to learn both API's from each other.

I like honeybee | bee but I am happy to go along with anything. I will probably comment again after reading through everything that you've linked to above. For now, does this mean that the only two relevant libraries are honeybee-core and honeybee-grasshopper (at least as they are named at present) ? Where does the Radiance code go in ? The library with geometry or the core library ?

[mostaphaRoudsari]

For now, does this mean that the only two relevant libraries are honeybee-core and honeybee-grasshopper (at least as they are named at present)?

Yes.

Where does the Radiance code go in? The library with geometry or the core library?

The core library unless there is specific need to add a geometry library on top of them like the gridbased recipe. But it will be always on top of the core implementation.

[chriswmackey]

@mostaphaRoudsari and @sariths ,

Sorry for being late to the conversation. This is all great and I understand the need for 3 different approaches for different types of geometry operations. I also agree that this is better than what we had before, which would have had a lot of redundant code between the different geometry interfaces. Putting the "export to OpenStudio" and "export to EnergyPlus" in the Honeybee core library (like the radiance library) also makes sense to me.

As for the naming, I feel pretty attached to the idea of calling the core libraries "honeybee" and "ladybug". I say this just because I know that, if another interface comes along that is perhaps not geometric but wants to take advantage of some of the basic Ladybug/Honeybee development to play around with EPW data, I would rather have people type "import ladybug" or "import honeybee" rather than "import bug" or "import bee." I almost feel like we are changing the name of the project to "bug" and "bee" if we go with this naming for the core libraries.

I am much more open to different ideas for the geometry library and I would even consider calling the geometry library "bee" if you like how "honeybee" and "bee" complement each other, @sariths . If I had to pick a top option, I would say "queenbee" for the honeybee geometry library, although I am not sure what to name the corresponding Ladybug geometry library (kingbug?). Perhaps "bee" and "bug" could be good names for the geometry libraries. I am really happy with anything that keeps the names of the core libraries as "ladybug" and "honeybee," though.

I'm interested in hearing your thoughts.
-Chris

[sariths]

@chriswmackey Kingbug ! We should probably consult some entomologists (just googled that) to find out if that is possible..

On a serious note, unlike you and @mostaphaRoudsari , I live exclusively inside the lighting and daylighting world. So, I am not completely sure what the larger implications of the nomenclature system will be.

I totally get the sentiment about retaining the names of the core libraries to be ladybug and honeybee. As I said before, I am happy to along with any names. I recommended deciding on this soon as changing the names later might break recipe type scripts which will be written using these libraries.

[chriswmackey]

@sariths ,
I agree that we should make a change soon to avoid revisions to the code. We should do it before the end of the week or soon after we hear @mostaphaRoudsari 's thoughts.

In additon to the fact that not many bugs have kings, I also realized that kingbug is probably not the best name for an insect that is supposed to be a lady. Bug and bee are sounding better.

-Chris

[mostaphaRoudsari]

Thanks @chriswmackey, @sariths. At least we all agree that this is the way to go.

Interestingly enough, for the exact same reason as Chris I was thinking that we should keep the libraries with geometry ladybug and honeybee as that's what the plugins are going to use and I was thinking keeping the names is important. Now that I read Chris's comment that also makes total sense to me too.

It seems the key is to keep ladybug and honeybee in the name of the libraries. What about following naming convention for libraries like cpickle and pickle? you Many people still write import cpickle and pickle, and it's very similar from there. We also have unittest and unittest2.

Something like ladybug and ladybugx, honeybee and honeybeex respectively for core and geometry libraries so ladybug and honeybee stays in the name of both libraries and you can do import ladybugx as ladybug for the geometry libraries and so on.

Once we make the decision I will go ahead and rename/re-structure the repositories.

[chriswmackey]

@mostaphaRoudsari ,
Your suggestion makes a lot of sense to me and I find the simplicity of it very elegant. I support implementing it if @ sariths is also on board.
-Chris

[sariths]

Hi @mostaphaRoudsari and @chriswmackey, @sariths is also on board.

[mostaphaRoudsari]

ok. I'm going to make the change for honeybee-core and honeybee-grasshopper repositories. It will potentially break everything. I will updated this issue once it's done. Meanwhile do not push to github!

[mostaphaRoudsari]

Done! It was easier than what I expected. We should be good to go... Welcome to honeybee and honeybeex libraries! no core and grasshopper anymore.

[chriswmackey]

Woo hoo!