Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request #16

Open
obucklin opened this issue Nov 12, 2024 · 5 comments
Open

Feature request #16

obucklin opened this issue Nov 12, 2024 · 5 comments

Comments

@obucklin
Copy link

Howdy!

I was hoping to implement some GH_Component override methods that only work on compiled components. See this image for reference:

image

This action creates a .ghpy file for the component, which is no longer editable as a python component on the canvas, but allows various overrides. have you guys considered this? Will the new cPython workflow for Rhino8 implement this?

Thanks!

@gonzalocasas
Copy link
Member

I think the major downside of .ghpy is that it doesn't work on Mac, or to be precise: it used to be that, we haven't tested if .ghpy + rhino 8 works on mac

@gonzalocasas
Copy link
Member

A quick check seems to indicate that this is still not supported on cpython + rhino 8 for mac:

image

@9and3
Copy link
Contributor

9and3 commented Dec 2, 2024

Howdy!

I was hoping to implement some GH_Component override methods that only work on compiled components. See this image for reference:

That would actually be cool. It's quite a pity that the compilation doesn't work on mac.

Still, I wonder if a component using modules, when compiled, would not require the modules to exist locally as .py somewhere. Do you know @gonzalocasas ?

@gonzalocasas
Copy link
Member

Howdy!
I was hoping to implement some GH_Component override methods that only work on compiled components. See this image for reference:

That would actually be cool. It's quite a pity that the compilation doesn't work on mac.

Still, I wonder if a component using modules, when compiled, would not require the modules to exist locally as .py somewhere. Do you know @gonzalocasas ?

I'm not entirely sure, but I think it would anyway be preferable to have those required modules as a python lib and use the # r: syntax in components to handle installation. Especially now that even the "pip from git" syntax works (i.e. # r: git+https://github.com/something/somerepo.git)

@gonzalocasas
Copy link
Member

Should we close this? Because I think it's not actionable on our side

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants