Hey guys,
I had a look at what you have been doing with Ladybug+/Honeybee+ and (first of all it looks really great) I was wondering if you plan to create a proper PyPI package?
Some of the stuff would be really awesome to be able to work with in CPython (and Python 3).
Cheers!
Christian
That is the plan! Interestingly enough the issue is not technical! See this:
Python 3 is another discussion. We have been going back and forth on the idea mainly because supporting the plugins and using Python 3 libraries in the core will be a very painful process.
Actually using both ladybug and honeybee as python libraries is as simple as cloning them using git and then add the paths to PYTHONPATH. I have been doing this for nearly a year.
Thanks for the input! I’m aware of that option and I tried it out some time ago. Unfortunately you have to use Python 2, which I’m not doing in any projects.
But what functions do you use from Ladybug? There is some good alternatives out there for some of the functions like: pyepw and eppy. So the question is if it is worth it for me to switch to Python 2?
That is great!
Yes, I guessed that Python 2/3 would be an issue. But it should be possible, right? I mean, many packages until recently been supporting both Python 2 and 3. Wouldn’t it future proof Ladybug Tools, in some way, as well? With the death clock on Python 2 and I have heard rumors that McNeel is considering supporting Python 3.
If you are interested, I would like to make a proof of concept for it.
Anyways I’m asking because, I think the functionality of some components could work well outside of Grasshopper, where you not necessarily would need a geometry.
Sounds good! I suggest to use Ladybug for a proof of concept. It is smaller than Honeybee. If you can come up with some general rules for the development we can follow your lead for Honeybee development.
Sure! Decoupling the core library from geometry dependencies is the main driver of developing the [+] libraries. See here.
I dont think there is any light-weight building science library that even remotely compares to Ladybug. In terms of what you can do with it, the possibilities are endless (provided that you take the time to understand the API).
Here is an example (sunpath in Python on my 7 year old laptop):
from __future__ import division,print_function
import matplotlib.pyplot as plt
import matplotlib
from dataproc.ladybug.epw import EPW
from dataproc.ladybug.sunpath import Sunpath
from mpl_toolkits.mplot3d import Axes3D
from matplotlib import cm
epwFile = r"C:\Users\sarith\Desktop\Birmingham.epw"
epwClass = EPW(epwFile)
sunPathClass = Sunpath(latitude=epwClass.location.latitude,longitude=epwClass.location.longitude,timezone=epwClass.location.timezone)
sunVectors = []
hourList = []
curveList = [[] for idx in range(24)]
radiationValues = []
for val in epwClass.directNormalRadiation:
sun=sunPathClass.calculateSunFromDataTime(datetime=val.datetime)
x,y,z=sun.sunVector
if sun.isDuringDay:
curveList[val.datetime.hour].append([x,y,z])
sunVectors.append([x,y,z])
radiationValues.append(val.value)
colorValues =[]
minRad,maxRad = min(radiationValues),max(radiationValues)
for val in radiationValues:
colorValues.append(matplotlib.cm.Reds(val/maxRad))
fig = plt.figure(figsize=plt.figaspect(0.5)*1.5)
ax = Axes3D(fig)
ax.grid(False)
for vectorList in curveList:
if vectorList:
xp,yp,zp = zip(*vectorList)
ax.plot(xp,yp,zp,c='g',alpha=1)
xs,ys,zs = zip(*sunVectors)
radPlot = ax.scatter(xs, ys, zs, marker='o',facecolors=colorValues,alpha=1,s=42)
m = cm.ScalarMappable(cmap=cm.YlOrRd)
m.set_array(radiationValues)
ax.view_init(elev=-163,azim=117)
plt.show()
(I “stole” the code to integrate into my own research repository, hence ladybug is under dataproc).
I’d appreciate “future-proofing” for Python 3. I’ve been using a lot of numpy/matplotlib with my Ladybug/Honeybee work recently, and I believe both of them will be dropping Python 2 support. I don’t think it’s much harder then what @sarith is doing in his snippet, using the future module for a couple of the changed operations like print… maybe change some old-style string formatting, etc.
Also we can easily add Python 3 as an additional interpreter to our test framework through Travis-CI’s configuration file. This is a really easy thing to check for.
@ChristianKongsgaard I haven’t used pyepw, but have tried out eppy, and Honeybee is definitely more reliable, and has much, much broader coverage for building energy modeling alone, and that’s without even getting into all it’s additional integration with Ladybug, Spider, Dragonfly, Radiance etc.
I finished making ladybug+ compatiable with Python3. It was quite easy, it took me around an hour.
I didn’t come up with any general ideas, since it was only a few statements that needed to be fixed.
I found a resource on Python 2<-> 3, which might be helpfull: http://python-future.org/compatible_idioms.html
@SaeranVasanthakumar, Thanks for the heads-up on. I had no idea that this was happening. I guess the time has finally come to make the switch(for me).
FYI here’s the official notice and list of projects dropping support and when: https://python3statement.org/. Clock is ticking!
We will move to python 3 but what should we do with naming the libraries on PyPI?
I love everything about this thread 
@ChristianKongsgaard can you get Apple to drop Python 2 in their OS as well lol
/em delrocco shudders from PTSD of using 5 versions of Python on a Mac Book Pro…
Why not call it ladybug_tools?
from ladybug_tools import honeybee as hb
import ladybug_tools.ladybug as lb
I think both import statements makes it clear what you are dealing with and people know the name Ladybug Tools
I love the import statements! Looks pretty good but then it means we have to deploy all the packages together as one and if one wants to use one of the plugins (say butterfly) then she had to download ladybug and honeybee and all comes with them. 
I think that most people would want the whole package and the convenience for them should outweigh the space saving for those who only want a single part. That said, it would be nice if you could make partial installs. Something like:
pip install ladybug_tools --without butterfly
However I don’t think that is possible. But maybe it was worth checking out further.
A hack you could do was to make the ladybug_tools package depend on the subpackages. So when you install ladybug_tools you get everything. But if you really only want butterfly, you could just:
pip install lbt_butterfly
Anyways, I don’t feel like the code base for all the libraries are that big, so there should be any storage problems. But if you only want to run Butterfly, but have to download the dependencies for everything else, that might be a problem.
So far @ChristianKongsgaard’s suggestions seem like the most elegant way to deal with the ladybug naming conflict we have on pypi.
I did a search of ways you might be able to exclude specific submodules in a pip install, but have so far only found hacky ways of achieving this: https://stackoverflow.com/questions/33441033/pip-install-to-custom-target-directory-and-exclude-specific-dependencies … which I think is getting overly complicated. If we could figure this out it would definitely be nice, but personally I don’t see myself using it, as I would prefer to download the entire ladybug_tools package.
A couple of other points to consider:
As long as you’re just installing source code, their is no real disadvantage to importing the ladybug, honeybee etc all at once (i.e the size impact is negligible). Is there a plan to include heavy, binary files in the pip install - is that even possible? In that case, I can see why installing individually makes sense.
I also think it’s more convenient to install one package of ladybug_tools, then have to individually download each of the main libraries one by one.
Having an overall package of ladybug_tools under which everything else goes into solves the naming conflict issue once and for all. That is, even if we do choose to have individual packages like honeybee_lib, ladybug_lib etc, there is no guarantee that eventually a future insect addition to ladybug won’t run into this naming conflict and we have to go through this exercise again.
I agree with @SaeranVasanthakumar. You can attach PyPI packages with “data files”, which is downloaded with the installation. In that way you could have Radiance, EnergyPlus etc. come with the installation. Besides convenience for the user, that also means that you would be in control of what version of Radiance etc. is distributed. Thereby you can check that Ladybug doesn’t break because of a new version of e.g Radiance.
Reviving this thead because of interest. Do we have a roadmap for PyPi deployment? If not can we agree on a way forward through a vote and get things moving? I personally agree with @ChristianKongsgaard 's proposed solution as the most straightforward. If we create a composite deployment called ladybug_tools to make it recognisable underpinned with a lbt_{package_name} format we can overcome the issue of naming.
Recipes should still be easily reusable so long as we start a tradition like matplotlib import pyplot as plt, pandas import pandas as pd or numpy import numpy as np etc…
Here’s a proposed roadmap if it does not already exists:
lbt-{package} deployment on PyPi for ladybug, honeybee, butterfly and dragonfly (released as 0.x.x so people know it’s not 100% production ready). As I understand it all bugs except butterfly already have a setup.py.