feat(handler): add index field to support chained handlers

[mostaphaRoudsari]

One of the creative usage of handlers that came up during the development was to use handlers one after another. Luckily the current schema could support this case:

    OutputAlias.linked(
        name='results',
        platform=['rhino'],
        handler=[
            # Preload results 
            IOAliasHandler(
                language='python',
                module='pollination_handlers.outputs.daylight',
                function='read_df_from_folder'
            ),
            # load preloaded outputs to Rhino with following method
            IOAliasHandler(
                language='csharp', module='Pollination.RhinoHandlers',
                function='LoadMeshBasedResultsToRhino'
            )
        ]
    )

The current implementation doesn't indicate which handler should be executed first. In this case since @MingboPeng was the developer of both the Rhino plugin and the Alias he knew how to get it to work but it wouldn't work otherwise.

This commit adds an optional index field to IOALiasHandler object to support supporting chained handlers. Default value will be set to 0. That means the code above will look like this:

    OutputAlias.linked(
        name='results',
        platform=['rhino'],
        handler=[
            # Preload results 
            IOAliasHandler(
                language='python',
                module='pollination_handlers.outputs.daylight',
                function='read_df_from_folder', index=0
            ),
            # load preloaded outputs to Rhino with following method
            IOAliasHandler(
                language='csharp', module='Pollination.RhinoHandlers',
                function='LoadMeshBasedResultsToRhino', index=1
            )
        ]
    )

This change will make it explicit that the Rhino platform should use the first handler for reading the results and execute that in Python - then pass the results to the second handler and run that one in C# which is the intended behavior.

[coveralls]

Pull Request Test Coverage Report for Build 880089404

• 1 of 1 (100.0%) changed or added relevant line in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.02%) to 49.007%

---

Totals
Change from base Build 879471130:	0.02%
Covered Lines:	1407
Relevant Lines:	2871

---

💛 - Coveralls

[ladybugbot]

🎉 This PR is included in version 1.25.0 🎉

The release is available on:

• GitHub release
• v1.25.0

Your semantic-release bot 📦🚀

[AntoineDao]

Hi @mostaphaRoudsari, can we slightly change this implementation to make it safer for the backend to integrate?

[AntoineDao]

Any chance we can replace this a nullable field rather than a default one? This will make the recipe digest more reliable when comparing with digests already present on the database.

index: Optional[int] = Field(None, description='An integer...'

[mostaphaRoudsari]

Hi @AntoineDao, Thanks for the note. I should have waited for your before merging this in. I remember we had issues with Optional when we used it in Honeybee Schema: ladybug-tools/honeybee-schema#121 (comment) - optional doesn't really translate to OpenAPI and that can cause inconsistencies.

I know that this might generate a new hash for the current packages the first time but it will be fine after that.

[AntoineDao]

I think waiting would have been helpful here. I'm a bit nervous about what will happen when we merge this into pollination-server so I will push it now and we can keep an eye on it to see if it breaks anything

[mostaphaRoudsari]

Sounds good! Based on what we talked about before - adding new optional fields should be fine but you never know. 🤞