[Sidefx-houdini-list] HDA script management

Andy Nicholas andy at andynicholas.com
Wed Feb 24 11:59:07 EST 2016


Okay thanks. I'm not too worried about the Contents.zip at the moment, 
although that might just be a false sense of security through my own 
ignorance on the matter. As long as I can modify and version the 
PythonModule and Dialog Script, then it's probably good enough for what 
I need.


On 24/02/2016 16:43, Lars van der Bijl wrote:
> it's been around many years. I don't think they will remove it anytime soon.
> save my bacon a few times to fix or find missing assets/files in production.
>
> you have the same for unpacking hip files.
>
> one issue with unpacked otls is that it still has compressed contents.gz
> inside of it so versioning it in something like git is not as simple.
>
> On Wed, Feb 24, 2016 at 3:01 PM, Andy Nicholas <andy at andynicholas.com>
> wrote:
>
>> 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),
>>> Cheers!
>>> A
>>>
>>>
>>>
>>> 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 and
>>>> HOM.
>>>>
>>>> I've done something similar recently for the Tools section of HDAs, and
>>>> it
>>>> works quite well.
>>>>
>>>> Cheers,
>>>>
>>>> Peter B
>>>>
>>>> On 23 February 2016 at 13:22, Andy Nicholas <andy at andynicholas.com>
>>>> wrote:
>>>>
>>>> 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
>>>>> pipeline
>>>>> modules, etc.) for the reasons I mentioned in my first email.
>>>>>
>>>>> So given that, then the only option is to store the code internally. But
>>>>> maybe there’s a hybrid approach that might work. What if we edit and
>>>>> store
>>>>> the code externally, and have a system so that when we save the HDA, the
>>>>> 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
>>>>> same
>>>>> 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).
>>>>>
>>>>> A
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 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
>>>>> Python
>>>>> 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
>>>>> versioning
>>>>> through Git. Ideally I'd like to have all my HDA Python code stored
>>>>> externally.
>>>>>
>>>>>> 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
>>>>> matches
>>>>> 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
>>>>> it's
>>>>> 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?
>>>>>>
>>>>>> Cheers,
>>>>>> Andy
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Sidefx-houdini-list mailing list
>>>>>> Sidefx-houdini-list at sidefx.com
>>>>>> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>>>>>>
>>>>> _______________________________________________
>>>>> Sidefx-houdini-list mailing list
>>>>> Sidefx-houdini-list at sidefx.com
>>>>> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> Sidefx-houdini-list mailing list
>>> Sidefx-houdini-list at sidefx.com
>>> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>>>
>> _______________________________________________
>> Sidefx-houdini-list mailing list
>> Sidefx-houdini-list at sidefx.com
>> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>>
> _______________________________________________
> Sidefx-houdini-list mailing list
> Sidefx-houdini-list at sidefx.com
> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list




More information about the Sidefx-houdini-list mailing list