Script -> Component

[sbaer]

Add the ability to convert a ghpython script into a stand-alone grasshopper component

[sbaer]

A good project to start for working on this would be to make ladybug into standalone components http://www.grasshopper3d.com/group/ladybug

[AndersDeleuran]

As in a creating .gha file from a Python script? That would be most excellent!

[AndersDeleuran]

Would it be possible to add a simple password protection while this is further explored?

Whenever I issue "code sensitive" components I have to wrap them in a cluster. This is obviously not very flexible and also means that you can't add custom type hints for the input parameters using the ghenv. So if it is "easy" to add a password protection (like on clusters) that would be great!

[dalefugier]

Hi Anders,

You might want to consider writing a compiled component, or GHA.

-- Dale

[AndersDeleuran]

Thanks Dale, Would that not require using C# or VB though? I really like how fast and easy it is to write and test a Python component. The only (well, main) thing missing is making them more "issuable" if that makes sense :) Best, Anders

[dalefugier]

Yes it would. But when you start talking about protecting your intellectual property, this is the direction you will want to take.

-- Dale

[golsby]

You may find this article interesting: http://stackoverflow.com/questions/261638/how-do-i-protect-python-code

Note that there is no such thing as perfectly protected, impenetrable code. Even code written by security experts at Apple can be cracked - JailBreaking is the term to search for. 

You might make it more difficult to read or understand, but you will never achieve the security you wish for. 

Note that the GHA password protection is weak and easy to work around for the slightly motivated amateur developer. 

— Brian Gillespie

On Fri, Mar 8, 2013 at 8:14 AM, Dale Fugier notifications@github.com wrote:

Yes it would. But when you start talking about protecting your intellectual property, this is the direction you will want to take.

-- Dale

Reply to this email directly or view it on GitHub: https://github.com/mcneel/ghpython/issues/43#issuecomment-14628032

[mostaphaRoudsari]

I think something in the middle of these two sides would also help. An option to edit the menu of the component will let you to remove the "open editor" for example. I tried to re-write David's script for customizing the menu of a component from Grasshopper SDK in Python. It didn't work. There are some issues with how the access is set for this classes in GHPython component...

Here is David's script:

public override bool AppendMenuItems(ToolStripDropDown menu) { Menu_AppendGenericMenuItem(menu, "First item"); Menu_AppendGenericMenuItem(menu, "Second item"); Menu_AppendGenericMenuItem(menu, "Third item"); Menu_AppendSeparator(menu); Menu_AppendGenericMenuItem(menu, "Fourth item"); Menu_AppendGenericMenuItem(menu, "Fifth item"); Menu_AppendGenericMenuItem(menu, "Sixth item"); // Return true, otherwise the menu won't be shown. return true; }

Here is my failed attempt:

import System

def newMenu(cmp, menu): cmp.Menu_AppendGenericMenuItem(menu, "First item"); cmp.Menu_AppendGenericMenuItem(menu, "Second item"); cmp.Menu_AppendGenericMenuItem(menu, "Third item"); cmp.Menu_AppendSeparator(menu); cmp.Menu_AppendGenericMenuItem(menu, "Fourth item"); cmp.Menu_AppendGenericMenuItem(menu, "Fifth item"); cmp.Menu_AppendGenericMenuItem(menu, "Sixth item"); return True

iMenu = System.Windows.Forms.ToolStripDropDown() cmp= type(ghenv.Component) cmp.AppendMenuItems = newMenu(cmp, iMenu)

---

Runtime error (MissingMemberException):attribute 'AppendMenuItems' of 'ZuiPythonComponent' object is read-only

I also tried to use GH_ActiveObject. No luck!

cmp = gh.Kernel.GH_ActiveObject cmp.Menu_AppendItem = newMenu(cmp, iMenu)

---

Runtime error (MissingMemberException): attribute 'Menu_AppendItem' of 'GH_ActiveObject' object is read-only

[AndersDeleuran]

Thanks Brian,

That is certainly true (see also this thread: http://www.grasshopper3d.com/forum/topics/password-protected-cluster-opening-solution), however I am not looking to to issue a highly secured component. Merely one which you cannot simply double click to view the source (which I assume is partly what Steve is suggesting in the OP). So for now this leaves me with the following three options:

1) Accept that's just how it is. 2) Wrap my Python components inside Grasshopper clusters. 3) Learn C# or VB.

None of which are really solutions if you are a Rhino.Python Grasshopper user. Hope you understand.

Best,

Anders

[bengolder]

This issue is really important for me. Currently, if I have a script that uses any external libraries, it's problematic to hand my script to another user. They would have to put any python packages into a specific folder and manually edit their python path in grasshopper. If there were a nice default way of handling external libraries, or a way of bundling external dependencies with a component, then I could actually share much more powerful python scripts. Currently, I would have to manually copy and paste entire python packages into the code editing component in order to make installation easier. The ease with which I can share a python component is decisive for how much I'll keep working with Grasshopper in the long run.

I am not at all concerned about protecting my code from users eyes. As discussed in the stack overflow discussing referenced above, protecting the python code seems difficult (even futile?), and potentially counterproductive. Can't we just include licenses if we're concerned? Even a compiled DLL can be reverse-engineered.

[piac]

Here is the first improvement for this thread. I realize this is just a small thing, but it should be still a first step for improving this. I would like to discuss some of your cases with you, so that maybe we can address the main remaining point.

From 0.5.99 onwards, sys.path will contain the folder where the Grasshopper definition is saved (if it is). This actually should make it easier to maintain a .py file that is referenced from the component.

@mostaphaRoudsari : what is the goal of removing the "edit" from the menu? Is it to make the component look more "native"? Or to avoid possible mistakes while editing the definition? Or is it to improve it from the point of view of intellectual property protection? My feeling is that I usually hope I could edit Grasshopper component's code and look into them @AndersHoldenDeleuran : are you usually looking for protection of the code itself that is in the editor, or some other package or module? @bengolder : when you said "any external libraries" did you mean .dll's or .py packages or modules? Or both?

[AndersDeleuran]

Hi Giulio,

For me the issue is mainly problematic when issuing GHPython components to users which should simply use the component, not edit the code. I've noticed that both students and architecture colleagues tend to open the editor and "fiddle about". Taking away attention from the task at hand, but also in some cases breaking functionality. So yes I guess it does boil down to converting a Python component to something more "native" like a compiled component.

That said, I also support the idea of being able to "bundle" any dependant modules and assemblies somehow. It can be a pain in the neck explaining to colleagues how to install the GHPython.gha, copy/paste Python modules and add reference to them via the EditPythonScriptEditor, or add them directly in the script and have them copy to a specific folder etc.

Just updated by the way, seems like smooth sailing so far. Great job.

Anders

[bengolder]

Hi Giulio,

I meant .py packages and modules. But .dlls would be similarly useful. I usually can get everything I need out between python modules and the .NET SDK. But I'm sure others would appreciate such functionality.

From 0.5.99 onwards, sys.path will contain the folder where the Grasshopper definition is saved (if it is). This actually should make it easier to maintain a .py file that is referenced from the component.

Awesome! Thank you! That makes things much easier!

[mostaphaRoudsari]

Hi @piac, I'm not really concerned with IP issues however I think access to the menu will help me to customize the component in multiple cases. As an example sometimes I rather to have double click to run the component and not open the editor. In this case I will probably still keep the open editor as an option in the menu that could be accessed by left click and select.

[AndersDeleuran]

Hi all,

I just tried compiling a .dll from a IronPython script file based on the links provided by @piac here: http://discourse.mcneel.com/t/best-way-to-distribute-python-script-without-exposing-the-source-code/3995/2

Using clr.CompileModules() I managed to compile a simple module (containing a function and a class) and then import the resulting .NET assembly in a GHPython component and use the function and class here. Perhaps this would be a way forward for compiling GHPython components?

Apologies if you are already exploring this avenue :)

Best,

Anders

[piac]

Yes, thanks, @AndersDeleuran -- we know this and we usually suggest it. The only issue with this is finding these .dlls and keeping them in the right spot. We are and have been exploring this for some time. This alone, though, will not create a usable assembly in Grasshopper (.dll). There need to be other changes for that. Thanks,

Giulio

[AndersDeleuran]

Ahh yes, I can imagine that being an issue. Looking forward to seeing what you come up with.Thanks for the update Giulio :)