Installing Schemas.usda

[dbaz]

Hi,
I'm trying to build my schemas library using USDv0.7.2 but it fails to build because the schemas.usda is not installed.

Could we get these base-type schemas.usda installed?

-Baz

[jtran56]

Filed as internal issue #142730.

[dbaz]

Also, it doesn't seem like codegenTemplates is installed.
I should really be putting PR's in for this kind of thing.
Thanks!

[chadrik]

Hi all, has there been any movement on this issue? If there has not, it would be great to start discussing how this should work so that we can possibly make a PR for it.

[spiffmon]

Hi Chad, We spent a little time discussing it, and got hung up on how to address the fact that each schema.usda directly subLayers other schema.usda files. Since we don't want to require the src structure to be the same as the inst structure, and we still want to allow running usdGenSchema from source, it wasn't immediately obvious what the best approach was going to be, so this got pushed from "we can just knock it out" to "going to require some thought".

…

--spiff

On 05/28/2017 09:01 AM, Chad Dombrova wrote: Hi all, has there been any movement on this issue? If there has not, it would be great to start discussing how this /should/ work so that we can possibly make a PR for it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#158 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF7qaB03bwLul5Gabi26rVMkV82qusCIks5r-ZpqgaJpZM4L1_mo>.

[chadrik]

Hmm... tricky problem. What solutions have you come up with?

Here's a very rough draft that comes to mind:

• create an environment variable for defining a schema search path
• give each schema.usda a unique name, e.g.. usdGeom.schema.usda
• use a custom asset resolver to find schemas on the search path. e.g.

  #usda 1.0
  (
      "This file describes the USD Geometric schemata for code generation."
      subLayers = [
          @usd.schema.usda@
      ]
  )
  

• set the env var during the build process

[spiffmon]

That's along the lines of one of the two approaches we'd discussed, and upon further discussion, seems like the more plausible one. Some notes: * The ArDefaultResolver should be up to the task - just need to ensure that you set its configuring env var PXR_AR_DEFAULT_SEARCH_PATH in usdGenSchema *before* causing an instance to get constructed and installed * Install the schema.usda files right alongside the generatedSchema.usda. Within schema.usda files, other schema.usda files would be referenced like so: @usdGeom/resources/schema.usda@ * You should be able to populate PXR_AR_DEFAULT_SEARCH_PATH from the (possibly slightly massaged) list of paths that PlugRegistry uses to search for plugins. That's not currently exposed, but we approve of adding an accessor on PlugRegistry to return the already-held list-of-paths (not sure if there's an initialization-order issue lurking there since PlugRegistry relies on initConfig to push the list of paths into itself...) Using libPlug as the oracle has the nice advantage that it will work properly with relocated builds. One note here is that in going through this exercise, we realized that a "standard" USD build will already fail to register schemas defined in "third party" locations, unless you have added those locations to a site-configured PXR_PLUGINPATH_NAME env var. So without that, usdGenSchema will be unable to resolve schema.usda files in Katana or Maya plugins.

…

On 05/29/2017 08:34 AM, Chad Dombrova wrote: Hmm... tricky problem. What solutions have you come up with? Here's a very rough draft that comes to mind: * create an environment variable for defining a schema search path * give each schema.usda a unique name, e.g.. usdGeom.schema.usda * use a custom asset resolver to find schemas on the search path. e.g. |#usda 1.0 ( "This file describes the USD Geometric schemata for code generation." subLayers = [ @usd.schema.usda@ ] ) | * set the env var during the build process — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#158 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF7qaGzNrd2pjtqc4JGZXPq0SK8jiy19ks5r-uWDgaJpZM4L1_mo>.

[chadrik]

@spiffmon Sounds like a plan. This will pave the way for releasing some open source projects, which should really help the community by providing some working examples.

On a related note, have you considered moving the third-party extensions into their own repos once this is complete? It would really improve compilation time in the general case, as well as jump-start the plugin ecosystem with pixar-blessed examples.

[spiffmon]

@chadrik, totally agreed that having example repos that extend USD would be great for the ecosystem, and is something we've discussed often. We're leery of migrating the plugins we support into their own repos until we have cooled off the API refinement iron, for the extra management it would introduce into our dev process.

…

On 06/01/2017 02:59 PM, Chad Dombrova wrote: @spiffmon <https://github.com/spiffmon> Sounds like a plan. This will pave the way for releasing some open source projects, which should really help the community by providing some working examples. On a related note, have you considered moving the third-party extensions into their own repos once this is complete? It would really improve compilation time in the general case, as well as jump-start the plugin ecosystem with pixar-blessed examples. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#158 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF7qaKq5WstZkTzk3rLPIwL54hZtBbIDks5r_zRHgaJpZM4L1_mo>.

[sirpalee]

@spiffmon Submitted a PR that implements your idea from above.

[sunyab]

Just wanted to note we've landed a series of changes to address this. This does affect how USD schemas get included in other schemas. Previously, the sublayer paths to do this had to be paths that pointed into a source tree. Now, we use a search path-based scheme so clients just have to mention the name of the library containing the schema.usda to be included. For example:

#usda 1.0
(
    "Example schema.usda file that uses schema.usda from usd and usdGeom"
    subLayers = [
        @usd/schema.usda@,
        @usdGeom/schema.usda@
    ]
)
...

Please let us know if there are any questions or concerns here. We'll close this out once these changes get pushed into the next release. Thanks!