Closed hansl closed 1 year ago
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/updocker-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)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.
vercel deploy
: https://vercel.com/docs/cli#commands
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.
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.
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. :)
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 :grinning:.
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.
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.
The name should be bikeshedded if necessary... Suggestions;
serve
,work
,do-the-thing
,start
, ...This is a new command that looks like this;
The new command does the following;
The command end when SIGTERM or SIGKILL is sent.