Today I had a look at localisation from the GUI.
Here's what I've got in mind.
Which would work with selection, and turn the packages tab into a kind of download manager.
Possibly with dynamically visible checkboxes in place of (or in addition to) the right-click menu options. That would unite the "localised" status and the method of performing localisation. And the same mechanism could then apply to the main view, to localise a whole context.
I also pondered about whether you'd want options for this. Especially for localising the entire context; there may well be some packages you aren't interested in, but they are in the minority. So then rather than selecting 40-50 packages, excluding 2, you could see a dialog box appear via the right-click menu, with options for what and how to exclude packages, e.g. a regex or some pre-defined regexes for the less technical artist/td.
During localisation, we'd also want the GUI to remain responsive, which prompts the question; what should happen when launching an application prior to localisation having finished?
- Ignore - Keep using the non-localised packages, the localised ones will be used next time around
- Responsive - Use the ones having been localised so far, and let the rest apply the next time around. But then the question is "when do we re-resolve, with the new packages?"
- We could do it e.g. per finished localised package, but that would incur an unnecessary amount of resolves, and they can be expensive, especially if not yet memcached.
- We could do it when the user hits Launch, to start an application. It would incur a slight delay to launching, as it would need to re-resolve. But that may be ok
- We could offer an explicit "Re-resolve" button the user can tick, to explicitly apply localised packages. That would work, and would mean the user would need an amount of smarts about what localisation means and how it works, but that may be ok.
- Lock - Prevent launching an application till localisation has completed. This method is technically simplest, but terrible for usability. Localisation can take minutes, maybe hours if the network (or internet connection, depending on where packages come from) is sluggish enough.
The (2) is probably the most intuitive, but opens up a number of issues.
- Re-resolving means losing the packages being kept track of by the GUI, how to we square that with the progress updates? And how to we keep localising packages overall, if packages known to the GUI keeps shifting around?
- We could establish a separate background process, potentially via
rez-localz(the library used for localisation) itself. Something we can communicate with over IPC that isn't dependent on the GUI remaining alive. That way, we could facilitate multiple GUIs being opened, and GUIs being closed. Without losing track of the localisation effort. That would of course increase the development effort, so the question is whether the benefit outweighs the cost. - Localisation could be entirely off-site; from a server of sorts, with read/write access to your local machine, like Ansible or Puppet. This would eliminate the strain and responsibility on the local machine, and enable the user to even shut down the machine, and have localisation continue on next boot. The GUI could interface over a socket. This would be stable, and expected, but incur both a large development effort and increase the prerequisites for making use of localisation with Allzpark.
For the time being, I'll start out simple (with ignore) to get the ball rolling. Odds are that's all we need to do, and it's intuitive enough as it is.
2 h later.
And there you go.
You'll notice a "Delocalize" option there as well, that's merely a shortcut to physically deleting the folder for that particular package version from the local user's home directory. Perfectly safe and unlikely to go wrong.
However, what I noticed was that deleting a package isn't something Rez likes to see happen. See, it caches almost every interaction and won't know that we've gone ahead and deleted a package. Normally, packages are immutable and shouldn't need to ever get deleted. Especially not interactively.
For now, I'll append one extra check to the "is_localised()" function responsible for checking the state of localisation (from rez-localz), but down the line it may be a good idea to implement rez rm.
1 h later
Ok, there we go. Full circle. I've also changed the name of (local) to (dev) to clarify the difference. Only issue is, (dev) means a package is coming from REZ_LOCAL_PACKAGES_PATH, and even though it's intended use is for development packages, it isn't exactly unambiguous. For now, it enough to make sense.
On top of that, even though these packages run fast, the process is happening in the background, so a large package (or slow connection) wouldn't interfere with the current session.
What remains is localizing multiple packages at once, and managing that process. But, only time will tell whether any of that is necessary, so this should do for now.
I'll add the --no-local option to the GUI, along with --no-filter to enable resolve using .beta plug-ins. Speaking of which, I'll add the actual filter being used to filter out certain packages to allzparkconfig.py so that it can be edited, as it's currently wired into the app. It'd likely you'll want your own filter (or no filter) for what is a non-stable package.