Skip to content

Instantly share code, notes, and snippets.

@mottosso
Created June 26, 2019 06:02
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mottosso/1b9feea2f2af9b3d35ab79fc6fe35402 to your computer and use it in GitHub Desktop.
Save mottosso/1b9feea2f2af9b3d35ab79fc6fe35402 to your computer and use it in GitHub Desktop.
25th June 2019 - Localisation pt. 2

Today I implemented a localisation MVP based off of the design document written yesterday.


Minimal Viable Product

A test-case for the viability of an idea. It went as expected, it's now able to handle the underlying basics of localisation, with these features.

  • Can copy new variants into an existing, localised package. E.g. python/3.7/os-windows when there's a python/3.7/os-linux there already.
  • Double-checks to see whether the package being copied has already been localised
  • Determines disk space, accurately, by first installing into a temporary directory
  • Visualises time taken per "step"
  • Finds latest version of request, rather than requiring an unambiguous version like rez cp. Will need this for resolved localisation (see below)
  • Try-before-you-buy, asks before actually writing to your precious local repository
  • Visualise version of Rez used, compatible with bleeding- and nerdvegas/Rez

Tomorrow

Next I'll resolve the request and localise all packages of a given context. This is how we'll be able to get a particular combination of packages for a given project and application to run locally and at max performance.

I figure that won't take all that long, so after that I'll return to the localisation automation, this time looking into RabbitMQ in place of memcached. Another feature native to Rez that I haven't yet looked into. Hopefully it's able to monitor calls to rez env. :fingerscrossed:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment