Fixes #34 Dev mode fix to load plugins from dev folder instead of OPENRV_ROOT_DIR & frame range from version

[georgeantonopoulos-bcnvisuals]

Fixes #34

Dev mode fix to load plugins from dev folder instead or OPENRV_ROOT_DIR

Load Frames gets frame range from version instead of representation first.

1. Added development mode support:

   • Introduced DEV_MODE flag controlled by AYON_USE_DEV environment variable
   • In dev mode, hooks are loaded from the current working directory for easier development

2. Enhanced frame loading logic:

   • Improved frame range detection by prioritizing version attributes over representation attributes
   • Added comprehensive logging throughout the frame loading process
   • Better handling of path formatting for frame sequences
   • More robust error handling and fallback mechanisms

3. Added detailed debug logging:

   • Track loaded nodes
   • Frame range detection process
   • Path formatting steps
   • Template and token handling

Testing notes:

1. Set AYON_USE_DEV=1 to test development mode hook loading
2. Test frame sequence loading with:
   • Sequences with frame range in version attributes
   • Sequences with frame range in representation attributes
   • Sequences without explicit frame range (should fall back to scanning)
3. Check debug logs to verify proper frame range detection and path formatting
4. Verify that single frames are still handled correctly
5. Test with both image sequences and video files to ensure proper format handling

[BigRoy]

I believe we should reverse this - we should prefer repre values over version values.

[georgeantonopoulos-bcnvisuals]

@BigRoy in our case (publishes from Houdini and Nuke) the frameStart and frameEnd were pointing to the same frame (1001) whereas the version had the correct frameEnd, maybe the issue is elsewhere?

[BigRoy]

Yes, sounds like some bug is going on for those publishes - that should not be the case or you're loading the wrong representation. Please provide a reproducable and we should investigate. But if a representation defines a frame range it should be a stronger opinion than the parent entity stating another frame range.

[georgeantonopoulos-bcnvisuals]

This log might help to debug, i'll look further into it to see where the representation attributes are being set,
How would you like a reproducible provided?

To me it looks like each frame has a different representation id, and all frames have frameStart and frameEnd of 1001. That goes for the representation_entity as well. Not sure if this is the default behaviour

Version attributes:
Version ID: c9cd8c78b71511ef88940615323c842b
Version attributes: {'comment': '', 'clipIn': 1, 'frameEnd': 1455, 'handleEnd': 0, 'pixelAspect': 1.0, 'source': '{root[work]}/civilizationvii/work/Film/NYD400/Lighting/civilizationvii_NYD400_Lighting_v056_alex.nindl.hip', 'frameStart': 1215, 'description': None, 'families': ['default', 'render', 'review'], 'handleStart': 0, 'fps': 60.0, 'site': None, 'ftrackId': None, 'intent': None, 'resolutionWidth': 1920, 'clipOut': 1, 'colorSpace': None, 'resolutionHeight': 1080, 'machine': 'ip-10-0-12-8.internal.bcnvisuals.com'}
Representation attributes:
Representation ID: ca003c38b71511efb1bc0615323c842b
Representation attributes: {'handleStart': 0, 'template': '{root[work]}/{project[code]}/publish/{hierarchy}/{folder[name]}/{product[type]}/{task[name]}/v{version:0>3}/{project[code]}{folder[name]}{product[name]}v{version:0>3}<{output}><.{frame:0>4}><_{udim}>.{ext}', 'fps': 25.0, 'clipIn': 1, 'path': '/mnt/production/project/civilizationvii/publish/Film/NYD400/render/Lighting/v004/civilizationvii_NYD400_renderLightingL_Helm_v004.1215.exr', 'frameEnd': 1001, 'handleEnd': 0, 'pixelAspect': 1.0, 'frameStart': 1001, 'resolutionWidth': 1920, 'clipOut': 1, 'resolutionHeight': 1080, 'extension': None, 'description': None}
Sequence frames: 1215-1455 (241 frames)

[BigRoy]

If each frame has a different representation then there is definitely! something wrong. Please provide a reproducable.

[BigRoy]

No need to define a logger here. Loader plugins come with their own logger. You can do self.log.debug for example on methods on the class instances (also works in classmethods if you need it)

[georgeantonopoulos-bcnvisuals]

Good to know thanks!

[georgeantonopoulos-bcnvisuals]

Noticed that the self.log.debug does not output to the terminal when --use-dev --debug args are used, might be doing something wrong :)

[BigRoy]

I suppose logging levels for Loaders log handlers do not default to debug level (not even in dev mode) @iLLiCiTiT ?
We might want to do that in ayon-core to ease debugging? Thoughts?

[iLLiCiTiT]

If that is the case then that deserves an issue in ayon-core indeed.