Testing components directly on Sculpt via the depot user local
Software is installed on Sculpt using the deploy mechanism that incorporates a caching component to keep the memory footprint for often used parts of the system constant. For the time being it is not contemplated to easily replace already loaded files and is therefor unsuited for testing components. However, there is still a way to perform the testing on Sculpt: the depot user local.
Every archive is automatically installed into the depot directory located in the root directory of the currently used file system. Normally, all files stored in there are accessed as ROM modules through a cached_fs_rom component by the deploy mechanism. The cached ROM modules are shared by all clients accessing them. To keep the implementation of the component simple, all files are loaded just once and stay immutable in memory for as long as they are in use by at least one client. Unused ROM modules will be evicted from the cache eventually in case there is memory shortage.
So, in theory a user could stop all clients using a particular modules and trigger an artificial memory shortage so that the component will empty its cache for all modules the user might want to change. This is impractical under normal operation to say the least. As it happens, cached_fs_rom is more or less an optimized variant of the fs_rom component. This component does not cache any files and will always create a new ROM module and thereby a copy of the file in memory on every request. Although wasteful during normal system operation, when files need to be changed on purpose, the component comes in handy.
The depot user local is special in that regard because all files from the depot/local directory are served via a fs_rom component. Being able to test components becomes therefor only a matter of installing or rather manually copying the archives in question to the local user directory. In an unmodified Sculpt system, the /rw/depot/local directory as well as the shared-folder /rw/shared directory used by a VM can be accessed from within the noux-system subsystem.
Let us assume I have a work-in-progress component called foobar for which I have already created a bin as well as pkg archive and copied the resulting directories into my shared-folder.
mkdir -p /rw/depot/local/bin/x86_64 mkdir -p /rw/depot/local/pkg cp -r /rw/shared/bin/x86_64/foobar /rw/depot/local/bin/x86_64 cp -r /rw/shared/pkg/foobar /rw/depot/local/pkg
From within Noux, the mkdir command will create the needed base directories - the local directory initially is empty - and the cp command will recursive copy all files. Deploying is then done by manually editing /config/deploy
<start name="foobar" pkg="local/pkg/foobar/wip"> <route> […] </route> </start>
The version string can be chosen freely (out of convience it is usually the date when using the depot tool automatically) but I normally stick to using wip when it is in progress or to current, which mostly is just a symlink, when I have multiple versions at hand. Since the files are loaded each time the component is started anew the runtime file can be tweaked easily from within Noux. This is especially helpful when a dependency is missing or the routing is messed up.
At some point, the component will eventually work as intended and it then makes sense to deploy it the common way, e.g., use the automatic deploy mechanism and a proper user.