<p><b>@bodymindarts</b> commented on this pull request.</p>

<hr>

<p>In <a href="https://github.com/bisq-network/bisq/pull/3718#discussion_r352761321">Makefile</a>:</p>
<pre style='color:#555'>> +# Deploy a complete localnet by running all required Bitcoin and Bisq
+# nodes, each in their own named screen window. If you are not a screen
+# user, you'll need to run each of the make commands manually in a
+# separate terminal or as a background job.
+#
+# NOTE: You MUST already be attached to a screen session for the
+# following commands to work properly.
+deploy: setup
+       screen -t bitcoin make bitcoind
+       sleep 2    # wait for bitcoind rpc server to start
+       make block # generate a block to ensure Bisq nodes get dao-synced
+       screen -t seednode make seednode
+       screen -t seednode2 make seednode2
+       screen -t alice make alice
+       screen -t bob make bob
+       screen -t mediator make mediator
</pre>
<p>Yes I understand the intention with having it all self-contained in the makefile and like the approach.<br>
It seems to be a trade trade-off between ease-of-use (via a wrapper script) and 'time searching for the exact commands being executed'. One is more focused on the developer who wants a streamlined workflow, the other on a first-timer just seeing how things work.<br>
In general I like being explicit (ie. no wrapper or indirection) and try to achieve that whenever possible, but in my experience (and I use a Makefile in every single project I do) when there are more than a few commands being executed or there are other complications having 1 level of indirection, like:</p>
<pre><code>something:
    scripts/do_something.sh
</code></pre>
<p>is an acceptable trade off, especially if it improves the dev-workflow (and active devs are probably the primary user of this interface). For first timers having to jump into the scripts folder for more information should be fine.</p>
<p>Another benefit is having the individual make commands closer together in the Makefile, which means not having to scroll so far when trying to assess what all the main commands are that are used to interface with the project as a dev. This also benefits first-time contributors.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/bisq-network/bisq/pull/3718?email_source=notifications&email_token=AJFFTNWEBYLPPK6GGJQBDBDQWVI2HA5CNFSM4JTEFEKKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCNS6ZYA#discussion_r352761321">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJFFTNTOUFP2VYNYPWAOVB3QWVI2HANCNFSM4JTEFEKA">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AJFFTNU77ESZHNFCDULBY4DQWVI2HA5CNFSM4JTEFEKKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCNS6ZYA.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/bisq-network/bisq/pull/3718?email_source=notifications\u0026email_token=AJFFTNWEBYLPPK6GGJQBDBDQWVI2HA5CNFSM4JTEFEKKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCNS6ZYA#discussion_r352761321",
"url": "https://github.com/bisq-network/bisq/pull/3718?email_source=notifications\u0026email_token=AJFFTNWEBYLPPK6GGJQBDBDQWVI2HA5CNFSM4JTEFEKKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCNS6ZYA#discussion_r352761321",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>