upgrade to v26.03

[ndeybach]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I was trying to look for recipes to lint for you, but it appears we have a merge conflict. Please try to merge or rebase with the base branch to resolve this conflict.

Please ping the 'conda-forge/core' team (using the @ notation in a comment) if you believe this is a bug.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/recipe.yaml) and found it was in an excellent condition.

[ndeybach]

@traversaro , thanks for the rerun of the bot on the bot PR.

Do confirm if me creating a separate PR since I am not a maintainer is the right way to deal with it though. I am not familiar with such situation.

After some patch fixes and other smaller changes, the 26.03 build seems to work perfectly on macos and windows CI. The linux CI did not trigger (maybe due to recent move to github workflow with conda smithy ...). Is it something to activate on the maintainer side ? I have it build successfully locally though on linux-64 fedora.

Also, I saw the current issue #9 , but I am not sure to understand its subtilities and if anything is needed to be done during this 26.03 upgrade ?

[traversaro]

Thanks for the work! Just a curiosity, are you using the openusd conda-forge for the C++ part or the Python part?

Do confirm if me creating a separate PR since I am not a maintainer is the right way to deal with it though. I am not familiar with such situation.

Yes, that is the correct way to go if you are not a maintainer and so you do not have write access to the autotick bot branches.

The linux CI did not trigger (maybe due to recent move to github workflow with conda smithy ...). Is it something to activate on the maintainer side ? I have it build successfully locally though on linux-64 fedora.

I guess I just needed to approve the job, it is now running.

Also, I saw the current issue #9 , but I am not sure to understand its subtilities and if anything is needed to be done during this 26.03 upgrade ?

That was fixed in #10, the issue is still open as we are missing a repodata patch to backport that fix for existing builds.

[traversaro]

Is there any reason for this constraint?

[ndeybach]

I added a pin because openusd cmake makes it as a searched pinned dep: https://github.com/PixarAnimationStudios/OpenUSD/blob/dae78ddbfe967ecedc2fd94da79d95a23e8b86f6/cmake/defaults/Packages.cmake#L221

Is that not correct ?

[ndeybach]

Thanks for the quick unlock of the github workflow and review !

are you using the openusd conda-forge for the C++ part or the Python part?

I am currently using the c++ part, but planning to also use the python part in the future.

Btw, on this, I usually build my recipes around split output to allow lower size installs and possibly not force python deps for those using only cpp side of things. For recipes like this one, is it possible to do a split after the fact without destroying the dependency chains ? Or is it now not possible ? (asking because if possible I could implement it in this PR ^ ^).

[traversaro]

are you using the openusd conda-forge for the C++ part or the Python part?

I am currently using the c++ part, but planning to also use the python part in the future.

Cool! If you like feel free to comment in PixarAnimationStudios/OpenUSD#3577 and PixarAnimationStudios/OpenUSD#3577 that this modifications (that are included here as patches) are also useful for you, thanks!

Btw, on this, I usually build my recipes around split output to allow lower size installs and possibly not force python deps for those using only cpp side of things. For recipes like this one, is it possible to do a split after the fact without destroying the dependency chains ? Or is it now not possible ? (asking because if possible I could implement it in this PR ^ ^).

That is a good question. For C++/Python packages, my preferred methods for doing split C++/Python packages is to make sure that each part can be built on its own, see for example https://github.com/conda-forge/idyntree-feedstock/blob/main/recipe/recipe.yaml . Given the specific structure of the openusd build system, this is not possible, so for any kind of split attempt we would need to use https://rattler-build.prefix.dev/v0.58.4/py-rattler-build/tutorials/multi_output_and_staging/ or something similar (xref: conda/ceps#102), to which I am not really familiar and I am not even sure if it can be used now in conda-forge recipes. Even if that is possible, however, openusd is quite peculiar: it uses python headers in its public headers, so for sure we can't avoid depending on python in the core C++ libopenusd library, and we can't avoid building a different variant of libopenusd for each Python minor versions. For sure we can split the files for the python bindings in their own package, but I am not sure how much size we save there. Something that instead I would really like to split in their own package are the tools, ideally in two separate cli and gui tools, so that we can isolate the big pyside dependency just to the openusd-gui-tools, that would be a great win.

In a nutshell, I think we could split the package in five outputs:

• libopenusd : C++ part, with run_exports
• openusd-python : Python bindings
• openusd-tools-cli : CLI tools
• openusd-tools-gui : GUI tools
• openusd : Output that depends on all the aforementioned outputs

However, given the complexity of this, I would strongly prefer to do that in its own separate PR to simplify reviewing and debugging, instead of coupling this change with a version update PR.

[ndeybach]

Thanks for the detailed answer @traversaro ,

Regarding the split, I have already tried the staging approach on local / private recipes. It works very well in those kind of setups.
Though, I could not add it rn to openimageio / opencolorio (my target for it) as it is not supported by conda forge until out of experimental feature in rattler-build. So we will probably need to await the CEP vote and proper support in conda forge after that.

The five outputs look great to me at first glance. And I hadn't thought about it, but the split with an openusd package that keeps them all would keep backward compatibility too, so I think its a great approach !

---

But I also agree that then it should be done in its own PR so I will try to revisit it once the stagging CEP is operational (I will do oiio/ocio first with them to get the hang of it ^ ^).

So if you agree on the review nit that you mentioned previously on libopensubdiv then are we good on the upgrade and we can merge ?

[ndeybach]

Hi @traversaro ,

Is there any blocker for merging now ? (I would like to experiment another build that has it as dependency over the weekend and there is some aspects in 26.03 that I would need)

[traversaro]

No! The 3.* pin on opensubdiv will need either a comment to be explained as it needs to be manually re-checked for consistency with the upstream CMakeLists.txt on every new release, but that is not blocking.

[ndeybach]

Thanks a lot for the reviews, comments and maintenance of openusd !

I'll do a quick PR to add opensubdiv comment before I forget about it.

Is something at the top of the file ok with you? Like :

schema_version: 1

# Some packages are pined relative to upstream cmake and need to be checked on version
# upgrades (check on the relevant commit you target, following is only pointers):
#   - opensubdiv (https://github.com/PixarAnimationStudios/OpenUSD/blob/dae78ddbfe967ecedc2fd94da79d95a23e8b86f6/cmake/defaults/Packages.cmake#L221)
#   - cmake (https://github.com/PixarAnimationStudios/OpenUSD/blob/dae78ddbfe967ecedc2fd94da79d95a23e8b86f6/CMakeLists.txt#L1)

context:
  name: openusd
  version: "26.03"