Arweave Should Not Build Before Being Stopped

[humaite]

This commit fixes an issue related to ./bin/stop script and ./bin/arweave.env. When stopping Arweave application in dev environment, a full release is always created. It is not clean and could probably leads to errors (even if was not the case previously).

The compilation is now made only when SCRIPT_ACTION variable is not set to "stop" or if ./bin/arweave-dev does not exist.

[JamesPiechota]

Rather than SCRIPT_ACTION... maybe some other more generic arg like "SKIP_BUILD" or something? That way we only have to set the parameter in scripts that need it. There are a lot of scripts that source arweave.env and currently don't set SCRIPT_ACTION

also if you can find a better way to do the arweave.env initialization. I don't love the current approach of setting environment variables, and since it's called via source we can't esily pass in command line arguments (which is why we have the kludgy "set an env var and then check it inside arweave.env")

The key thing is making sure all scripts which run arweave (e.g. arweave-server, start, stop, benchmark-xxx, data-doctor, shell, test, et....) all are launched by default under the same environment

We had some hairy bugs before where the two scripts (e.g. start vs. arweave-server) were launched with different flags which caused some hard to debug performance issues.

[humaite]

Rather than SCRIPT_ACTION... maybe some other more generic arg like "SKIP_BUILD" or something? That way we only have to set the parameter in scripts that need it. There are a lot of scripts that source arweave.env and currently don't set SCRIPT_ACTION

Correct. I will rename it SKIP_BUILD.

also if you can find a better way to do the arweave.env initialization. I don't love the current approach of setting environment variables, and since it's called via source we can't esily pass in command line arguments (which is why we have the kludgy "set an env var and then check it inside arweave.env")

What do you really want? Something like the following code?

./bin/arweave start
./bin/arweave stop
./bin/arweave console
./bin/arweave test

The best way would be to have only one entry-point and not many, a bit like bitcoin or ethereum do but it will be kinda complex right now. Do you have the list of the most used commands, like, we can start with a script doing the commands used 80% of the time, and then improve it when needed.

The key thing is making sure all scripts which run arweave (e.g. arweave-server, start, stop, benchmark-xxx, data-doctor, shell, test, et....) all are launched by default under the same environment

Does arweave really need environment variable? It seems the only environment needed by arweave is TERM (see apps/arweave/src/ar.erl). So yeah, creating an unique entry-point controlled by flags can be a first step.

[humaite]

Added SKIP_BUILD variable.

[JamesPiechota]

yeah a single entry point might be better, but also agree not for this PR. Main issue with a single entry point is just the one extra layer of nested flags. E.g. the benchmark-xxx and data-doctor commands already have the definition of a subcommand and then flags specific to that subcommand. So we'd essentially need to have command, sub-commands, and sub-sub-commands which get hairy.

Probably best to defer that change until we can revisit how we luanch all this stuff in general (e.g. if we're moving towards a form of UI, maybe the commandline complexity becomes less of an issue) So for now, no change. We just have to make sure each of the multiple endpoints are launched in a consistent state (as they are now)

[JamesPiechota]

I don't think you need the export. I'm always fuzzy on that, but if you export skip_build I think it might persist in the shell environment after you run the script? If so, then we don't want that.

e.g. SCRIPT_DIR and SCRIPT_ACTION aren't exported, but are still picked up by the source arweave.env line which is all we need for now.