nerdvegas/rez — pull request #93 by mstreatfield (2014-08-21 07:57:48+00:00)
Title: Remove Validation From Resources

This change is a first pass at moving validation out of `resources.py`/`package_resources.py` and into the `DataWrapper` as discussed. And primarily it's had little impact if anything it might have made rez a tad slower...

The classes defined in `resources.py`/`package_resources.py` no longer provide a schema, but do perform some level of data manipulation (for example, ensuring the version number is valid, and that the package name matches). This manipulation is not possible in the `Schema` layer and so has to remain here. As `_PackageBase` already derives from `DataWrapper` (via `ResourceWrapper`) there wasn't too much to do on that side of things.

Some resources in `package_resources.py` appear to be orphaned. For example the `ReleaseInfoResource` refers to the rez 1 release metadata files but the data it provides doesn't get used. Previously this file would still be validated, now it is not. The assumption is that a consumer of this resource would also implement it's own `DataWrapper` layer to provide this.

I haven't removed CombinedPackageFamilyResource and CombinedPackageResource. However, I'm not immediately clear how these would be implemented as a result of these changes with the new setup.

That aside, I am not sure how, by removing code, I've managed to not get a greater speed improvement as expected. Resolving a moderate number of packages (using `ResolvedContext` directly, not `rez env`) doesn't really show any improvement. Maybe I've missed something very obvious...?

One very specific area where I can get see a loss of ~0.5 seconds in a moderate example is the `load` method of `BaseVariantResource`. This sets a list of `variant_requires` on the `_internal` property which is then used by the `subpath` method on the `Variant` class. Creating the necessary `Requirement` objects is relatively slow. For the moment I've delayed this by doing the cast in the `subpath` method, but technically it doesn't belong here. But the previous implementation must have been doing something similar.