That's cool but not the same.

Actually, it is the same since your are referencing a function in another location.

for the same reason I prefer wrangles than vex files in disk.

What do you mean by this and how does that relate to the 'feature' that was suggested?
Again, in both cases you're still referencing a function externally from your code and still using a wrangle where the function is applied.

andreuparri
Including functions from other nodes would also allow for importing vex functions from hdas which is something I many times wished was possible.

But you're still having to define where and what you are referring too.
So the idea of doing away with 'dependancy management' is not eliminated. You still have to manage the references(if they change), although now within the hip file itself; But it's still management.

I am referring to the following feature I suggested:
#include /obj/geo/anotherwranglewithfunctions

BabaJ
Again, in both cases you're still referencing a function externally from your code and still using a wrangle where the function is applied.

In the "feature" I was suggesting the definition of the functions leaves in another wrangle instead of a vex file on disk.

Which has the same advantages as using wrangle vs files.

andreuparri
In the "feature" I was suggesting the definition of the functions leaves in another wrangle instead of a vex file on disk.

Which has the same advantages as using wrangle vs files.

But what's the advantage, other than personal preference which I can't 'argue' with, of referencing it to a wrangle vs. local file in $HIP ?

BabaJ

andreuparri
Including functions from other nodes would also allow for importing vex functions from hdas which is something I many times wished was possible.

But you're still having to define where and what you are referring too.
So the idea of doing away with 'dependancy management' is not eliminated. You still have to manage the references(if they change), although now within the hip file itself; But it's still management.

Yes, it just makes more sense to me to work with nodes (even if they have dependencies) since is just the way Houdini works.

I would personally use this very often where I need the same functionality (sometimes with small variations) in many branches but is not generic enough to make and hda.

BabaJ

andreuparri
In the "feature" I was suggesting the definition of the functions leaves in another wrangle instead of a vex file on disk.

Which has the same advantages as using wrangle vs files.

But what's the advantage, other than personal preference which I can't 'argue' with, of referencing it to a wrangle vs. local file in $HIP ?

To clarify I'm always thinking of local functions that are used in multiple wrangles in a single hip file. When a single wrangle with function definitions is updated, multiple wrangles calling those functions in the same hip file get updated automatically. Like a mini embedded hda but much simpler.

It does add anything new is just more convenient, faster and self-contained.

Another advantage is that you could have hdas that simple hold vex functions and loaded when you need them. Yes you can have this with included files but not as tidy imo.

For global functions to use in many diferent hip file it does make more sense to have them in a file in an include folder.

andreuparri
Yes, it just makes more sense to me to work with nodes (even if they have dependencies) since is just the way Houdini works.

Yes, this is the way Houdini 'works'. It has a consistent $HIP 'system' that makes it easy to reference your functions in a file.

I would personally use this very often where I need the same functionality (sometimes with small variations) in many branches but is not generic enough to make and hda

If you're wanting to make modifications often then you are defeating the purpose of using functions to begin with; or you are in a development phase of working out your functions.

Look to reduce your functions to essential and repeatable processes that can work with modifications before and after the function outside of the function itself.

If you can't see how to do that, why don't you take advantage of vexpressions and/or presets which bring in your 'general' setup that you can modify directly in each node instance to that specific need. Then after a while when you see where it can be simplified and applied/used repeatedly as a function. Then when you have settled for a function defined the way you like, you can remove those vexpressions/presets.

BabaJ
But what's the advantage, other than personal preference which I can't 'argue' with, of referencing it to a wrangle vs. local file in $HIP ?

I suppose it is in a way a personal preference but in another way I just think it makes more sense to be node based since is the houdini philosophy in the first place.

Advantages I see wrangle vs text file on disk:

• Selfcontained. I cannot be lost that easily. If it exist in the scene is much easier to find by other artist.
  
• Easy to have multiple version. Its easy to test diferent versions by simply duplicating the wrangles.
  
• Can use presets which hopefully get even more functional in future versions.
  
• Can easily shared with hdas.
  
• Using relative paths inside node networks can easily duplicate both the definition wrangle and the wrangles calling the functions. This way would make the dependencies a bit more flexible.
  

To me it's also got a lot to do with vex being accessible and easy to explore. Why do I need to mess with files and extra windows or terminals if I'm exploring an idea? We should be able to have easily user defined functions in our code. What other language does this?

andreuparri
To clarify I'm always thinking of local functions that are used in multiple wrangles in a single hip file. When a single wrangle with function definitions is updated, multiple wrangles calling those functions in the same hip file get updated automatically.

But you can do that with your reference to the function in vex/include.
Just update that function in the file and since all the wrangles are referencing that, they reflect the change.(The wrangles do need a 'refresh' though).

Also, again from my other post, if you are constantly making changes to the function then you are really in a development phase and why would you try to be developing a function that is sitting in different contexts throughout your hip? You're going to give yourself a 'headache' in terms of debugging and is irrelevant whether your are referencing your function from another wrangle or on file. It's 'best' to develop a function in it's own context where you are controlling the variables and number of them to look at in assessing how you finally want your function to perform.

It does add anything new is just more convenient, faster and self-contained.

Like I said before - $HIP vex/include is self-contained within Houdini.

Another advantage is that you could have hdas that simple hold vex functions and loaded when you need them.

But you already can have HDAs which have their own internally defined vex functions within them without external reference to files.

andreuparri

BabaJ
But what's the advantage, other than personal preference which I can't 'argue' with, of referencing it to a wrangle vs. local file in $HIP ?

I suppose it is in a way a personal preference but in another way I just think it makes more sense to be node based since is the houdini philosophy in the first place.

Advantages I see wrangle vs text file on disk:

• Selfcontained. I cannot be lost that easily. If it exist in the scene is much easier to find by other artist.
  
• Easy to have multiple version. Its easy to test diferent versions by simply duplicating the wrangles.
  
• Can use presets which hopefully get even more functional in future versions.
  
• Can easily shared with hdas.
  
• Using relative paths inside node networks can easily duplicate both the definition wrangle and the wrangles calling the functions. This way would make the dependencies a bit more flexible.
  

So basically a note and a way to read it’s context as an #include

Soothsayer
Why do I need to mess with files and extra windows or terminals if I'm exploring an idea?

There is no difference between an extra code window of a text file vs an extra window pane of the source wrangle node of your function that you are working with.

We should be able to have easily user defined functions in our code.

You can, referencing your function in a file doesn't make it any more difficult to define and use in your code.
The only difference is the location of the defined function.
Actually to me, the target location of the defined function makes more work for me on new creating new projects/hip files.
Since now I have to go open the source hip (if I can remember which) and sort through the nodes to find where it is.
With a $HIP vex/include I can simply look at that directory look at the names of the different files and easily/quickly find the file I need to copy and paste into my new $HIP directory that has the new project. I save a lot of time.

What other language does this?

All languages use external file references. Just because you don't see it, doesn't mean it's not 'there'.

#include read("/vex/awaiting_backlash","as_vex")

Wouldn’t a repo as package solve the portability issue, if it’s saved as local $HIP/vex/include and at the same time to some sort of global user defined vex dir? sourcing it from global dir solves you remembering where it is, and it doesn’t change the workflow for the rest of the users… so when the time comes for the include you have a similar to attribs dropdown with all available includes, and when you want to save include something like save selected as vex include, it would have to be "live"… just thinking outloud

EDIT:
also those include fields would be written into .hip or hda, in a similar fashion as vops.

hMonkey
Advantages I see wrangle vs text file on disk:

Selfcontained. I cannot be lost that easily. If it exist in the scene is much easier to find by other artist.

How is the going to get lost anymore than a .hip file can get 'lost'?
It's sitting in a Houdini 'ecosystem' under $HIP. I personally back up the directory that holds the .hip file.
Because it not only has my functions but also other subcatagory folders like geo and others.
The artist is actually going to have an easier and quicker time finding the functions if they always look to vex/include,
rather than possibly having to hunt through a network to find that one 'original' source node that has the function being
referenced.

hMonkey
Easy to have multiple version. Its easy to test diferent versions by simply duplicating the wrangles.

It's easy to make and test multiple named versions as well with an external referenced file by simply copying and pasting
within the same file or new file with different name. If you're only at development stage then you can put your function code
directly in the wrangle, since like you say you're only at development stage. So as it is Houdini already has the 'feature' you
are looking for.

hMonkey
Can use presets which hopefully get even more functional in future versions.

Externally referencing you vex functions does not preclude you from not being able to use presets.

hMonkey
Can easily shared with hdas.

Vex functions can already be defined and used within an hda.

hMonkey
Using relative paths inside node networks can easily duplicate both the definition wrangle and the wrangles calling the functions. This way would make the dependencies a bit more flexible.

How is this any different that ones reference to a file vs. another wrangle? A wrangle can be duplicated with the same code that references the function externaly and is just as flexible.

hMonkey
#include read("/vex/awaiting_backlash","as_vex")

#include <No_Slashes_Required_You_Are_Utilizing_$HIP_Ecosystem_Made_For_You.h>

BabaJ

hMonkey
Advantages I see wrangle vs text file on disk:

Selfcontained. I cannot be lost that easily. If it exist in the scene is much easier to find by other artist.

How is the going to get lost anymore than a .hip file can get 'lost'?
It's sitting in a Houdini 'ecosystem' under $HIP. I personally back up the directory that holds the .hip file.
Because it not only has my functions but also other subcatagory folders like geo and others.
The artist is actually going to have an easier and quicker time finding the functions if they always look to vex/include,
rather than possibly having to hunt through a network to find that one 'original' source node that has the function being
referenced.

hMonkey
Easy to have multiple version. Its easy to test diferent versions by simply duplicating the wrangles.

It's easy to make and test multiple named versions as well with an external referenced file by simply copying and pasting
within the same file or new file with different name. If you're only at development stage then you can put your function code
directly in the wrangle, since like you say you're only at development stage. So as it is Houdini already has the 'feature' you
are looking for.

hMonkey
Can use presets which hopefully get even more functional in future versions.

Externally referencing you vex functions does not preclude you from not being able to use presets.

hMonkey
Can easily shared with hdas.

Vex functions can already be defined and used within an hda.

hMonkey
Using relative paths inside node networks can easily duplicate both the definition wrangle and the wrangles calling the functions. This way would make the dependencies a bit more flexible.

How is this any different that ones reference to a file vs. another wrangle? A wrangle can be duplicated with the same code that references the function externaly and is just as flexible.

I said no such thing

BabaJ

hMonkey
#include read("/vex/awaiting_backlash","as_vex")

#include <No_Slashes_Required_You_Are_Utilizing_$HIP_Ecosystem_Made_For_You.h>

it was pointing to /vexOPs where all your notes live

external includes are a nightmare unless they come from stable global source
for individual HDA/Wrangle utility functions it's not ideal to depend on external file as then you are risking breaking previous versions of the HDA/.hip file when the external code changes or you will be left with dozen of duplicates of the external file to cater to all possible modifications that were done, none of that is good for making sure that all hip files in your project will continue to work as before after opening

also using words like Dev stage don't mean anything, during the production you are always in dev stage and need to address fixes and needs as they come up, without breaking the hundreads of .hip files that worked fine with previous versions even if technically the code was not completely correct

for me it'd be enough to be able to reference vex code stored inside of the HDA definition's extra files section
then that would provide best of both worlds
- easy management and versioning
- easy access through opdef: as long as that HDA is installed, doesn't have to be present in the scene
but AFAIK you cannot include using opdef: currently, or can you?
(also for wrangles withing that HDA it sill be self contained which is the most use case anyway, but any other node could still include using opdef: from any other installed HDA, at your own risk)

tamte
external includes are a nightmare unless they come from stable global source

That depends on ones pipeline, conventions, etc.

As for myself, I've never had any glitches or difficulties for the 5 years I've been using external includes.

My own exception would be in the case of an HDA, in which I would want to 'include' the vex functions directly in the HDA itself.
You actually told me how to do that a while back, I just haven't implemented that yet as I have yet haven't ran into 'nightmares' to push myself to start doing it.(although for HDAs I still think it's a better way other than my current way).