dfx develop command

[hansl]

The name should be bikeshedded if necessary... Suggestions; serve, work, do-the-thing, start, ...

This is a new command that looks like this;

dfx develop

The new command does the following;

• start a replica and a bootstrap server
• in a loop:
  • create canisters that don't exist yet
  • build the canisters
  • install the canisters, with upgrade if necessary
  • wait for files to be changed anywhere in the project

The command end when SIGTERM or SIGKILL is sent.

[gobengo]

With regard to the color of the bike shed..... I like dfx up or just dfx.
a la

• vagrant up: https://www.vagrantup.com/docs/cli/up
• docker-compose up: https://docs.docker.com/compose/reference/up/ . docker itself doesn't really have an equivalent to 'dev' I think. You have to call docker build [flags] and docker run [flags] the way you want (or use a higher level tool like docker-compose to do that for you)
• kube up - though this isn't a CLI, it's an exaple of the 'up' meme

Over the last couple years, now (recently renamed to 'vercel' when they raised VC to make it trademarkable) became a popular easy-to-use way for web developers who don't know how (or don't prefer to) to manage their own servers to deploy simple web apps: static html websites, node.js web servers, and eventually any dir with a Dockerfile in it.

• They call theirs vercel deploy: https://vercel.com/docs/cli#commands
  • BUT historically you just had to type now (or npx now to fetch-and-run), and the default command is 'deploy'). People seemed to like that. Of course our 'default behavior' could be a little clever and only do dfx develop if you are in a dfx project pwd. If not, we can show the user some helpful getting started instructions on stderr, link to sdk docs, and echo dfx --help (current behavior)

(descending order of preference:

dfx #default command is 'develop' or 'up' or whatever'

# pick one
dfx up
dfx dev
dfx develop
# plenty of other things I'd prefer less. Ultimately even `dfx develop` is a color of bike shed I wouldn't mind driving past every day.

[hansl]

I'm not in favor of dfx without any subcommands, as people often use it after installing to see what happens. That should be the help (default path).

up is fine by me, but I'm afraid it might not be the best name.

[gobengo]

I'm not in favor of dfx without any subcommands, as people often use it after installing to see what happens. That should be the help (default path).

I intended to sketch a candidate solution that preserved that default behavior, but also behaved such that if you did happen to run it in a dfx project, and dfx has access to an interactive shell, that we would not just show you the whole help reference (in my experience, many web devs make useful apps while still being a bit intimidated by UNIX & command line tools), but additionally also ask if you're doing other very common tasks like 'up' or maybe 'file bug report' that, if so, you can learn about and initiate within 1-2 additional keystrokes.

up is fine by me, but I'm afraid it might not be the best name.

I'd wager there is no objectively best name, and also that we'd never settle that wager. I definitely always learn something, though, from a survey of subjective preferences from others, so am only sharing to submit my two cents.

Reiterating:

Ultimately ... dfx develop is a color of bike shed I wouldn't mind driving past every day.

I will aspire to bow out of this bikeshedding now unless others' opinions are shared. Take mine or leave it, no sweat. :)

[lsgunnlsgunn]

My .02:
RE: alternative names for "dfx develop" -- I now Hans favors "dfx watch" but that feels a little passive to me, and I came up with few ideas (dfx design, dfx make) but I have one I think would be very cool and somewhat unique:
dfx workshop
I think of this as a verb, when you have an artistic endeavor--like a play or a film--that is work-in-progress, something you want to tinker with, possibly collaborate on, before unveiling it to the world.
You could also think of it as a place, where you work on wood-cutting or building a model train or inventing flubber.
It suggests something that's not finished but is being refined, important enough to spend time on, but not yet ready for public consumption.
if we think of ourselves as "makers" or "builders" maybe this hints at that mindset.
Okay, probably only I think it's cool. But hey, worth a shot 😀.

[hansl]

I'd wager there is no objectively best name

start is my preferred choice. It comes with "starting the day", "starting dfx", "starting development". It's already taken in dfx but I'm (IMHO) okay with breaking that asap rather than adding a new command. dfx start is already a workflow command (it's dfx replica + dfx bootstrap), so it's easy for users to move to.

[lsgunnlsgunn]

I would prefer not to reuse command names start or build so that we can do the "usability preview" without changing any existing doc. Having the same names mean different things depending on which version of dfx you have installed or are currently using seems like it would be very confusing or cause a lot of unnecessary context-switching.