[Sidefx-houdini-list] HDA script management
andy at andynicholas.com
Wed Feb 24 10:01:36 EST 2016
BTW, I couldn't find any reference to hotl in the latest Houdini docs.
It's not being deprecated is it? I wouldn't want to start building a
workflow around something that's being dropped (cough... Softimage)
On 24/02/2016 14:59, Andy Nicholas wrote:
> Thanks Peter, that's super useful. I guess it then reduces to a very
> similar workflow to building a regular bit of source code.
> I just need to wrap my head around how to manage the editing of it
> all. I'd obviously prefer to edit the parameter and their layout in
> Houdini, while deal with the Python externally. So first thoughts are
> to write a python script that uses hotl to export the HDA to a
> temporary location and then copy the DialogScript file (and any other
> non-python files) to the repository location. Will have a think about
> that, but it seems to be the best way to go.
> Thanks for your help (and to everyone else too),
> On 23/02/2016 21:34, Peter Bowmar wrote:
>> Hi Andy,
>> Yes, for sure you could edit externally then build the Python into
>> the HDA
>> for publish. "hotl" (the command line tool) will be one of your friends
>> here, unless you want to pull an Hscript license and do it via Hython
>> I've done something similar recently for the Tools section of HDAs,
>> and it
>> works quite well.
>> Peter B
>> On 23 February 2016 at 13:22, Andy Nicholas <andy at andynicholas.com>
>>> Okay, so having thought about it further, I’m partially going to
>>> answer my
>>> own question here…
>>> It seems that it’s never gonna be a good idea to import Python modules
>>> live into an HDA (unless they’re built-ins or stable core studio
>>> modules, etc.) for the reasons I mentioned in my first email.
>>> So given that, then the only option is to store the code internally.
>>> maybe there’s a hybrid approach that might work. What if we edit and
>>> the code externally, and have a system so that when we save the HDA,
>>> code is *copied* into the HDA so that it gets stored within. That way,
>>> there’s never an issue with synchronising versions. If it could be
>>> automated (and lets face it, we wouldn’t want to do it manually), then
>>> there’s no reason you couldn’t get it to trigger a git commit at the
>>> time to update the repo.
>>> If anyone has any thoughts about that as an approach or if you’ve done
>>> something similar, I’d love to hear (on or off list).
>>>> On 23 Feb 2016, at 15:40, Andy Nicholas <andy at andynicholas.com> wrote:
>>>> Hey folks,
>>>> I've been getting further into HDA authoring and have been writing
>>>> a lot
>>> of HDA embedded python scripts. One thing I'm missing is not writing
>>> in my favourite IDE (PyCharm) with all the benefits that brings,
>>> like reuse
>>> of code, being able to do Diffs, and being able to manage code
>>> through Git. Ideally I'd like to have all my HDA Python code stored
>>>> So I was just wondering if anyone had got a workflow going with
>>> versioning HDAs and externally imported python modules? Seems like
>>> it could
>>> be a can of worms having to make sure that the version of the asset
>>> the correct version of imported python module. Any HDAs used on a
>>> job would
>>> have to have a corresponding python module available in the path and
>>> hard to see how conflicts could be managed easily (especially since
>>> multiple versions of the same HDA could be used in the same Hip file).
>>>> Anyone have any experience trying to manage this in their set up?
>>>> Sidefx-houdini-list mailing list
>>>> Sidefx-houdini-list at sidefx.com
>>> Sidefx-houdini-list mailing list
>>> Sidefx-houdini-list at sidefx.com
> Sidefx-houdini-list mailing list
> Sidefx-houdini-list at sidefx.com
More information about the Sidefx-houdini-list