Today I populated the website with content.
Learned today that there are Windows 10 versions that report..
$ C:\Users\marcus\Desktop>systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
OS Name: Microsoft Windows 10 Pro
OS Version: 10.0.17134 N/A Build 17134
$ python
>>> import platform
>>> platform.platform()
'Windows-8-6.2.9200'
>>> from rez.utils.platform_ import platform_
>>> platform_.os
'windows-6.2.9200'
Which Rez is using for it's implicit os
package. Notice how systeminfo
is reporting 10.0.17
, but Python's platform.platform()
reports 6.2
? Now look at results from another machine.
$ C:\Users\marcus\Desktop>systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
OS Name: Microsoft Windows 10 Pro
OS Version: 10.0.18362 N/A Build 18362
$ python
>>> import platform
>>> platform.platform()
'Windows-10-10.0.18362'
>>> from rez.utils.platform_ import platform_
>>> platform_.os
'windows-10.0.18362.SP0'
That's mad. I had to update the platform_map
to this:
platform_map = {
"os": {
r"windows-6(.*)": r"windows-10",
r"windows-10(.*)": r"windows-10",
},
}
Which effectively makes any modern version of Windows into Windows 10.
The rez-scoopz
project had been using "RemoteSigned" so far which had worked well in my tests. But what I hadn't tested was hosting the package on a network disk, which required an escalated execution policy. The error itself was very hard to track down, due to a blunder in the rez-scoopz
command-line interface.
$ rez env scoopz -- install curl
Initialising Scoop 2019.05.15.6... ok - 0.04s
Reading package lists... fail
$
Ok, thanks for that. I wasn't able to remind myself what the command-line arguments were, because passing --help
got overtaken by the rez python
command we're using under-the-hood.
$ rez env localz -- install --help
usage: rez python [-h] [-v] [FILE]
Start a python interpreter or execute a python script within Rez's own
execution context. Unrecognised args are passed directly to the underlying
python interpreter.
positional arguments:
FILE python script to execute
optional arguments:
-h, --help show this help message and exit
-v, --verbose verbose mode, repeat for more verbosity
Further developed the landing page to make room for what makes Allspark different and useful.
Before | After |
---|---|
Discovered a Rez-like environment management and build-system tool called Spack that looks very interesting. It's built by the science community and with similar goals in mind as Rez.
https://www.youtube.com/watch?v=D0p5xpsboK4
- Package management
- Complex dependencies
- Builds
- Environment management
- Written in Python
- No Windows-support
Going to have to take this for a spin. Looks like there's a lot we can learn; for one, they've already implemented class-based packages.
Finally, we're able to move away from first-impressions and onto second-impressions; the actual content.
Landing page is looking good, increased the number of stars to the project by 330% (from 3 to 10). :)
However there are far too many assumptions baked in for anyone else to make use of the projet yet, and considering I'm also getting the developers and artists at Anima up to speed with it now is the time to make proper documentation for it, so that's what I'll be doing tomorrow.
Be end of this week, I expect a self-contained guide for how to get setup with Allspark and in the process have worked out which parts need the most attention.
Localisation has also reared its head recently, and I'll be introducing this more as we go along. The current method of localising is manual, but effective. Once we're comfortable with how it works, we can start automating it via Ansible.
These are some remaining features I'll be building into Allspark starting next week.
- More localisation testing
- More testing on Linux
- Cosmetics on how to change the project in the GUI
- Cosmetics in the Info tab
- HDPI support (at least to a functional level, at the moment I think it'll look garbled)