mlegner
commented
3 months ago This is a very good suggestion. The release process will change significantly as we transition from devnet to testnet/mainnet and open-source the Walrus codebase. The current somewhat convoluted procedure is mostly due to the fact that we don't want to open-source the core Walrus codebase just yet but wanted to use Walrus Sites as a show case for what can be done with Walrus.
We will definitely take your proposal into account when reworking our release process.
kkomelin
Problem/Motivation
Currently user first installs the main walrus tool and only then Walrus Sites (site-builder), which complicates the installation procedure and consequently can increase the "bounce rate" (users who gave up).
Take Docker Compose script for example, it was initially a separate project, installed separately, and later it was included into the main Docker tool as a sub-command. That's because many users preferred Docker Compose config to long Docker cli commands. Docker Compose proved its place in the main package by improving user experience significantly.
Also, the site-builder script name is too generic which may conflict with already installed cli scripts in the user system.
Proposed Resolution
We may not yet know how many users will use the Walrus Site Builder script (makes sense to measure through telemetry) but the fact that users need to install two separate tools in different ways affects use experience.
Therefore, I'd like to propose improving the installation process by including the Walrus Site Builder script into the main Walrus installation package either by using Git submodules or a custom build script. It could also become a walrus tool subcommand.