2.27.0 (2019-01-24)
Implemented enhancements:
- facilitate variant install when target package is read-only #565
Fixed bugs:
- timestamp override no working in package copy #568
- shallow rez-cp can corrupt package if there are overlapping variants #563
Merged pull requests:
- Develop #570 (nerdvegas)
- Issue 568 #569 (nerdvegas)
- Issue 565 #567 (nerdvegas)
- Issue 563 #566 (nerdvegas)
2.26.4 [#562] Fixed Regression in 2.24.0
- #561 timestamp not written to installed package
2.26.3 [#560] Package.py permissions issue
- #559 package.py permissions issue
Fixes issue where installed package.py can be set to r/w for only the current user.
2.26.2 [#557] Package Copy Fixes For Non-Varianted Packages
- #556 rez-cp briefly copies original package definition in non-varianted packages
- #555 rez-cp inconsistent symlinking when --shallow=true
- #554 rez-cp doesn't keep file metadata in some cases
There were various minor issues related to copying non-varianted packages.
2.26.1 [#552] Bugfix in Package Copy
- #551 package copy fails if symlinks in root dir
This was failing when symlinks were present within a non-varianted package being copied. Now, these
symlinks are retained in the target package, unless --follow-symlinks is specified.
2.26.0 [#550] Build System Detection Fixes
- #549 '--build-system' rez-build option not always available
To fix this issue:
- The '--build-system' rez-build option is now always present.
- To provide further control over the build system type, the package itself can now specify its build system - see https://github.com/nerdvegas/rez/wiki/Package-Definition-Guide#build_system
Unfortunately, the 'cmake' build system had its own '--build-system' commandline option also. This was possible because previous rez versions suppressed the standard '--build-system' option if only one valid build system was present for a given package working directory. This option has been changed to '--cmake-build-system'.
2.25.0 [#548] Various Build-related issues
- #433: "package_definition_build_python_paths" defined paths are not available from top level in package.py
- #442: "rez-depends" and "private_build_requires"
- #416: Need currently-building-variant build variables
- #547: rez-cp follows symlinks within package payload
The biggest update in this release is the introduction of new variables accessible at early-bind time: building, build_variant_index and build_variant_requires. This allows you to do things like define different private_build_requires per-variant, or a requires that is different at runtime than it is at build time. In order to get this to work, a package.py is now re-evaluated multiple times when a build occurs - once pre-build (where 'building' is set to False), and once per variant build. Please see the updated wiki for more details: https://github.com/nerdvegas/rez/wiki/Package-Definition-Guide#available-objects
A new build-time env-var, REZ_BUILD_VARIANT_REQUIRES, has been added. This mirrors the new build_variant_requires var mentioned above.
rez-depends has been updated to only include the private_build_requires of the package being queried (previously, all packages' private build reqs were included, which is not useful). Recall that the previous release fixes the issue where private_build_requires was being stripped from released packages.
The entirety of a package definition file can now see the extra build-time modules available via the package_definition_build_python_paths config setting. Previously, only early bound functions could see these.
There was an issue with package copying (and thus the rez-cp tool) where symlinks within a package's payload were expanded out to their source files at copy time. The default now is to keep such symlinks intact - but hte previous behavior can still be accessed with the rez-cp --follow-symlinks option.
This release adds a new tool, rez-cp, for copying packages/variants from one package repository to another, with optional renaming/reversioning. The associated API can be found in src/package_copy.py.
- #541
- #510
- #477
- Package definition file writes are now atomic;
- private_build_requires is kept in installed/released packages;
- Fixes include modules not being copied into released packages;
- File lock is no longer created when variant installation happens in dry mode.
- #532
Bug was introduced in: https://github.com/nerdvegas/rez/releases/tag/2.20.0
- #528
Two new features are added in this release:
Override any config setting with an env-var. For any setting "foo", you can now set the env-var REZ_FOO_JSON to a JSON-encoded string. This works for any config setting. Note that the existing REZ_FOO env-var overrides are still in place also; if both are defined, REZ_FOO takes precedence. This feature means you can now override some of the more complicated settings with env-vars, such as package_filter.
Track context creation and sourcing via AMQP. Messages are published (on a separate thread) to the nominated broker/exchange/routing_key. You have control over what parts of the context are published. For more details: https://github.com/nerdvegas/rez/blob/master/src/rez/rezconfig.py#L414
The embedded simplejson lib was removed. The native json lib is used instead, and for cases where loads-without-unicoding-everything is needed, utils/json.py now addresses that instead.
- #512
- #526
PR: #213
Package/variant/family search API is now available in package_search.py. This gives the same functionality as provided by the rez-search CLI tool.
PR: #501
- #490: Fix alias command in Windows when PATH is modified
- #489: Fix cmd.exe not escaping special characters
- #482: Fix selftest getting stuck on Windows
- #389
- #343
- #432
- #481
PR: #523
- #492
The rez-python command now supports all native python args and passes those through to its python subprocess - so you can now shebang with rez-python if that is useful.
More broadly, rez commands now parse CLI args correctly for each case. Many commands previously accepted rez-env-style commands (eg rez-env pkgA -- somecommand -- i am ignored), but simply ignored extraneous args after -- tokens.
- #522
- #514
The problem occurred because the preprocess function was attempting to be serialized when the package definition is cached to memcache. However, this function is stripped in installed packages; furthermore, caching "developer packages" (ie unbuilt packages) was never intentional.
This release disables memcaching of developer packages, thus avoiding the bug and bringing back originally intended behavior.