Wasmer: I do NOT like wax magic!

[KSXGitHub]

Motivation

The new release of wasmer provides wax which is just a symlink to wapm. This means that wapm must do magic, this also means that wax cannot be renamed to something else.

Proposed solution

Create a separate program named wax that executes wapm execute.

[Hywan]

Sorry if the design of wax annoys you. We will come back to you shortly.

[frank-dspeed]

he simply wants to have separated code that's not a priority he can issue a pr to help that this faster happens.

[KSXGitHub]

@Hywan It's not just an annoyance. It's a limitation. I have explained that limitation.

@frank-dspeed I don't want to sound rude, but proper punctuations may help me understand you better.

[frank-dspeed]

@KSXGitHub give me an example of the limits I do not understand magic it is not in the source.

as far as i understood you. You are not happy that wax shares code with wapm

[syrusakbary]

Sorry for the delay replying here.

Yeah, it's true that wax is doing magic in some sense. We are using a strategy coined by busybox, that basically uses only one binary and multiple commands (symlinks) pointing at it. In that sense, it will look up on the command name to execute certain logic.

Before choosing that approach we discussed about having instead a wax with:

#!/bin/bash
wapm execute ${@}

However, we discarded it because it introduced a small extra lag. At the same time, our strategy still allows that, so anyone can still do the wapm execute ... strategy in cases where is need.

@KSXGitHub I'm aware you maintain Wasmer packages for some Linux distributions. Is the strategy we are using bad for packaging it or so?

Note: I completely get that the current stratgy can be a bit more annoying, but since we also expose the wapm execute ..., people don't have to rely on wax directly (or they can create their own wrappers (as exposed before).
Any insight on why this could be a limiting factor would be great, thanks!

[frank-dspeed]

@syrusakbary maybe it should be better like git :) wasmer pm => wasmer-pm
a single binary that calls other binarys.

i did never saw issues like this in git so it is a save design choice :)

[syrusakbary]

Wapm and WAX share a lot of logic (almost all). If we were to split out in two different binaries, the download sizes will be much bigger. In that sense wax is built to be "inside" wapm rather than a plugin.

However we are investigating the wasmer pm => wasmer-pm approach for other kind of plugins :)

[frank-dspeed]

@syrusakbary I think he would be happy if wax would not be a symlink when it would be something that calls wapm this is solved :+1:

I can imagine he has problems copying the files and then the symlinks do not match some stuff like that I am around in opensource for a long time I can predict such stuff.

[KSXGitHub]

@syrusakbary

Before choosing that approach we discussed about having instead a wax with:

#!/bin/bash
wapm execute ${@}

However, we discarded it because it introduced a small extra lag. At the same time, our strategy still allows that, so anyone can still do the wapm execute ... strategy in cases where is need.

That extra lag is insignificant in my opinion. You can optimize it by not relying on bash or any third-party shell interpreter, instead, create a Rust program that executes wapm execute directly.

I'm aware you maintain Wasmer packages for some Linux distributions. Is the strategy we are using bad for packaging it or so?

True. Symlinks are tricky to copy. The only way to create wax is to enter installation target (/usr/bin/) and create a new wax -> wapm symlink, which is an unusual practice. This essentially recreates implementation details of wax, which is also something I am not happy about.

[syrusakbary]

Sounds good @KSXGitHub, thanks for your feedback!

We will fix it for the next version of Wasmer 🙂

[syrusakbary]

We are working now in a refactor that will land soon in master.

We solved the wax logic there :)

[syrusakbary]

Thanks to the refactor that has just landed in master, we have updated the code regarding wax, and is now it's own bash script file.
https://github.com/wasmerio/wasmer/blob/master/Makefile#L147-L148

Closing the issue