CommunityStandup: Can we rename K?

[glennc]

In the community stand up today @shanselman asked if we should rename K, KPM, and KVM.

His suggestion was dotnet, so that we would have:

k -> dotnet
kpm -> nuget
kvm -> dotnetsdk

I've heard other suggestions about this in the past, and kpm changing to nuget seems fairly common, most people are ok with that.

The other decision is what to call the command that runs an app, the version manager name falls out of that. Dotnet makes sense

This issue is to discuss that, what do you all think of changing K to dotnet, so that the command to run an app is “dotnet foo”?

[clintkolodziej]

I agree its probably best to keep the language brand (similar to node, ruby, python, etc), though since these are commands that are going to be typed quite often the challenge would be to keep them short also. The best of both worlds would involve having a few aliases for those advanced users, while keeping the full name for those who are new, or for tutorial / documentation purposes. I also like the idea of keeping the names pretty much the same so you can logically group them together, rather than have to remember that nuget is the package manager for dotnet. As dotnet is now open source there (hopefully) will be quite a few new cross platform users switching over from other languages, and having one less thing to remember during transition would certainly help.

k -> dotnet -- with alias 'dn'
kvm -> dotnetvm -- with alias 'dnvm'
kpm -> dotnetpm -- with alias 'dnpm'

PS - I still am rather partial to k, kvm, kpm, but I'm realistic that to keep branding and lower the entry bar for new users it is probably better to come up with something that indicates the command is for the dotnet language.

[clintkolodziej]

The reason I wasn't a huge fan of "nuget" and "dotnetsdk":

"nuget" already has it's own executable and could be confused with this (as Jon Galloway mentioned) unless the nuget.exe is changed to do everything that kpm currently does.

"dotnetsdk" makes me think of a 300+ MB download with examples, libraries, etc. Really what this command is is a version/runtime installer and/or selector, so it should be named appropriately. SDK always makes me think of something heavyweight, where as this is really a lightweight program. It doesn't need any negative connotations as lot of non-Microsoft people have about the old, heavy .NET monolithic framework that came bundled with Windows.

On a slightly separate note, it is actually a bit odd that we are talking about the K commands in the scope of ASP.NET, as it actually is more of a general-purpose runtime (with dependency injection, etc built in) that can be used for console apps, or apps that run a webserver (Kestrel, Microsoft.AspNet.Hosting, etc). I would actually think it would make more sense to move k, kpm, kvm outside of the ASPNET realm into something all on its own to prevent confusion that this can only be used for ASP.NET websites, apps, etc. I actually think of this more like node where the runtime can bootstrap any program you want, its up to you whether you launch something that instantiates a web listener, or something that listens on the command line.

[reecebradley]

I agree with Clint and the before-mentioned ideas.
k -> dotnet -- with alias 'dn'
kvm -> dotnetvm -- with alias 'dnvm'
kpm -> dotnetpm -- with alias 'dnpm'

Anything with SDK in the suffix always reminds me of lots of tooling and bunch of executables that will give me stuff I want and lots of stuff that I don't normally use.

I also would be ok if nuget snuck in there somehow instead of dotnetpm. People might be like, "Another package manager for .NET? Where does it pull it's packages from? A new repo?"

So Maybe...

kpm -> nugetpm-- with alias 'ngpm'

It might bridge the gap for some people to not feel like there is some new repo out there. After all, the full title is NuGet Package Manager.

[elishnevsky]

How about dotnet, dotnpm, dotnvm? Same length, same prefix. Easy to remember.

[analogrelay]

I don't know for sure, but I would imagine the idea of the "rename" to nuget is that kpm and nuget would be unified into a single executable that can work in both contexts. I may be wrong though.

I agree that 'dotnetsdk' sounds too cumbersome. Crazy idea: Things like 'nvm' include the ability to run a specific version of the node runtime without the whole "use" pattern: nvm run 0.10 ... <args to node> .... Could we just roll all that together into the 'dotnet' command? So 'dotnet' would have commands like:

• dotnet use 1.0.0
• dotnet run -- <args> (uses currently selected framework)
• dotnet run 1.0.0-beta -- <args> (runs with specified framework)
• dotnet run <alias> -- <args> (runs with framework defined by alias)
• dotnet install ...
• dotnet list

The "--" mirrors the usage of those patterns in tools like git. It signals the end of arguments for the "run" command and that the remaining arguments are for the app being run. If the arguments for the program don't conflict with arguments to run, then it is optional: dotnet run foo bar baz

So in my example:

• k -> dotnet
• kvm -> dotnet
• kpm -> nuget

[clintkolodziej]

@elishnevsky, I like the dotnet, dotnpm, and dotnvm also, its a pretty good compromise between branding and command length.

A unified command would also be pretty cool as @anurse mentioned, though that would probably require a lot of extra development effort beyond what has already been done. Also, I don't know for sure, but I suspect k/kpm/kvm was a convention borrowed from node/npm/nvm (or ruby/gem) so it would take it further from that, and be less comfortable for current open-source programmers who are familiar with separate commands to run code, versus install packages.

[yaakov-h]

@anurse So you would combine k and kvm into dotnet, and kpm and nuget into nuget?

That makes the most sense to me so far, and keep the names friendly too.

@clintkolodziej

it would take it further from that, and be less comfortable for current open-source programmers who are familiar with separate commands to run code, versus install packages.

If there's a command to run code and a command to install packages, why keep kvm separate? Shouldn't that fall under 'running code'?

[analogrelay]

I'm not sure it would take much more. The runtime package itself would come with a native executable, much like it does now (klr) to do the actual booting. Then dotnet would incorporate the functionality currently found in k and kvm. The k command is barely a command at all, implementation-wise it's just a simple call to klr.exe.

I realize it differs from the existing node/ruby environments, but we don't have to duplicate them :). We just want to take inspiration and build something (we hope is) better (or at least more suited to our scenarios)

[clintkolodziej]

@yaakov-h yeah, I wouldn't be sad if kvm was combined into the dotnet command in my opinion, though I can see not wanting to change things too much as there have already been a ton of videos, tutorials, etc documenting it as a separate command. One thing that may be beneficial on combining these two commands is that I see a whole lot of forum questions from node developers on how to keep the runtime updated, they all assume it is something like node upgrade. Combining k and kvm would certainly be easier for new folks to get up to speed faster since it is all related to the runtime.

@anurse I agree, the goal here is to make it easy, or easier to use than the existing programming languages. An additional goal is to let people who already have a bias against .NET know that this is a break with the past of monolithic, OS-bundled frameworks, and is now something lightweight and modular like the other popular frameworks (node, ruby). Naming and structuring this in a modular way could help with that goal, which could lean toward separating the functions into separate commands as they currently are. I could go either way as long as it is easy to use.

[schotime]

Very good ideas @clintkolodziej and @anurse.

So maybe you only need

• k and kvm -> dotnet -> dn
• kpm -> dotnetpm -> dnpm

That would make sense.

[himanshpal]

I like the idea for ngpm by @reecerbradley
Since it's all about asp-net, may be we can go with something like

• k and kvm -> aspnet -> with alias 'an'
• kpm -> ngpm

[michaldudak]

@himanshpal - it doesn't have to be just about ASP.NET. As the guys at community standup pointed out, running a console app with KRE is also possible (BTW I do hope it won't be named ASP.NET Console App in final version of Visual Studio as IMO it doesn't make a lot of sense), so dotnet, dotnpm or dotnvm sound good.

One question, though - we're thinking about renaming the tools, but what about the KRE? Are we going to drop the K there too?

[clintkolodziej]

@doodack - I agree, I disagree with naming K after ASPNET, and I also hope the VS console template isn't named ASP.NET Console App. As I mentioned above even keeping K/KVM/KPM in the AspNet GitHub repository seems like an odd choice as it is really a generic runtime similar to Java/Node that can create console apps, network services, websites, etc. It would really make more sense to just call it a Cross Platform Console Application (as standard console apps would be an exe and not able to run on *nix), or something like that.

[jarrettv]

+1 dotnet and nuget

[nvivo]

Agree with the idea of @anurse. dotnet and nuget seems to be a good option.

The idea of a git-like command where "dotnet list" as an alias for "dotnet-sdk list" is great, and it standardizes the interface but decouples things and they can evolve at their own pace.

I find adding "pm" and "vm" unnecessary. nuget rhymes with dotnet, and I find that cool. =)

I just wonder how to make nuget work with both packages. Do all packages have unique names between platforms? Would it be something like "nuget --runtime:corefx install packagename"? Looks strange.

About using ASPNET in the name, I think the team already said .NET Core will be the "main" .net at some point in the future. Once things like IO, Collections and etc start moving on CoreFx, it is just a matter of time before things like WPF get compiled on top CoreFx, and then it is just another runtime. ASP.NET was just the first target for the refactoring, so the names were used, but I doubt the team will use "aspnet" in any names once things reach production.

[analogrelay]

Let me expand a bit on my idea. I don't think it defeats the modularity of the system and I think there is a benefit in having a unified front-end. Honestly, I actually don't think our primary goal here should be to sway people entrenched in the industry who have misconceptions about .NET. I do think we have a shot at showing them this is different, but I think it's the newcomers we should be working on. A unified front-end makes the "getting started" experience super clean. One command, with rich help.

The current world:

• klr - A Native executable that boots the CLR and calls into a VERY basic entry-point provided on the command line
• k - A shell script (CMD/SH) that provides specific arguments to klr to boot our "K" Application Host which initializes all the fun services (DI, etc.). Currently the primary entrypoint
• kpm - The "build tool" for K. Builds packages, compiles code, installs packages, etc.
• kvm - A tool to manage versions of the above commands

Right now, klr, k and kpm all come together in one package. kvm is a simple shell script. We basically understand the idea of merging kpm and nuget into a single command, so let's put that aside for now. In my proposal, we replace those commands with the following:

• klr -> clrhost (name TBD) - The Native executable that boots the CLR
• k -> clr (name TBD) - A dirt-simple shell script that just boots a "K" app (with services like DI, etc.), nothing else
• kvm -> dotnet - A rich shell script that provides a front-end to the commands above. Nothing prevents users from using clr and clrhost natively, and the community can totally build alternate front-ends to replace dotnet.

Really, all this can be achieved by the following steps:

1. Add a kvm run command which behaves as I discussed in my first comment
2. Rename the things
3. Make sure the acquisition process (i.e. "installing" K) provides the dotnet command and a simple way to update it. In theory, VS could provide it, but doesn't have to (it could be a secondary "install command line tools" process, much like installing kvm works today). VS would likely be using the raw clr and clrhost entry points, possibly using data like aliases (which don't really depend on the kvm script itself, it's just a file convention)
4. Update samples and docs to use the dotnet command.

[glen-84]

I don't like x"vm" because the acronym makes me think of a virtual machine.

I like the idea of a single "dotnet" command as mentioned by @anurse, that can be used to manage KREs as well as to run the application itself.

Question: Is it theoretically possible to run desktop applications as well, if you selected a non-core CLR that included WinForms or WPF, or are those "bootstrapped" differently?

It's still a bit blurry to me the specifics of what each tool does (KLR vs KRE vs CLR, KPM vs Nuget, exactly how KLR runs an application, etc.).

[Alxandr]

@glen-84 It's both theoretically and actually possible (as in, I've done it). Though, I hacked it...

Problem is that applications on windows starts either in console mode, or in window mode. You can (as I've understood it) open a console (at a later time) if you're in window mode, and you can even (I think) start windows from console applications, but getting rid of the console? I don't know about that...

[SharpNoiZy]

+1 dotnet and nuget

[ewahner]

I like @anurse idea of a unified command. I don't really understand what each tool does, but if I were to just type

c:> dotnet /?
c:> Usage: dotnet [tool] [command] [option [...]]
c:> tools recognized
c:> nuget, kpm, kvm

Then you could do a dotnet nuget help or dotnet kpm help or dotnet kvm help.

[directhex]

I have no strong feelings about the "right" option, but "kvm" is a big problem on Linux, where the namespace for commands is flat, and "kvm" is already used by the Kernel Virtual Machine command

directhex@marceline:~$ kvm --version
QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.5), Copyright (c) 2003-2008 Fabrice Bellard

We really need not to use "kvm", if the cross-platform aspirations are true.

See also aspnet/dnvm#46

[slang25]

I think dotnet is the best name for k, as Scott says, it's completely unambiguous. It is short and friendly.

I love @anurse's suggestion of putting kvm under "dotnet use", you have one less command to remember (because like @ewahner said, you can discover it by dotnet /?) and as @glen-84 pointed out it sounds like a virtual machine.

nuget is a much better name for kpm IMO, however I agree that it must be the same exe as nuget to avoid confusion, in which case they would be tightly coupled and this may complicate future releases.

I have no preference over d or dn as aliases, dotn looks wrong and isn't much shorter that dotnet, I think it must be 1 or 2 characters.

Keep up the great work

[peterblazejewicz]

I've been chatting about vNext at work and terms like k, kvm and kpm are very unfamiliar, strange (type of WT*) to folks using VisualStudio line of tools - while dotnet or nuget will rings a bell instantly. nuget is commonly used and recognisable as tool - while kpm restore has really no meaning or connotation.

People can do aliases in shell - so dotnet or nuget can be aliased according to preferences to shorter version - just as it happens with git command. It's much harder to alias k I think.

Thanks!

[Bartmax]

Wanted to add another possible solution to the Nuget.exe conflict : renaming the nuget.exe
Not sure if this can we worse or not.

I like the dotnet (k & kvm) and nuget (kpm)
NuGet is a good name for kpm and can be aliased to ng.

[motowilliams]

I would like to see just a single executable entry point then have various parameters and switches to engage different features including what nuget does today and what it will do tomorrow.

I'd also mention to thinking ahead to how build servers might be interacting with the platform as well. We have a well-known uri where we can get the nuget.exe today and having a single exe for this version would help keep things clean. The dotnet.exe I just grabbed to restore packages is the same one to spin up a web server and run some integration tests — swell.

New version available? dotnet.exe upgrade ... done!

Hungry? dotnet.exe sandwich ... yum!

Having more than one app to manage isn't the end of the world. Aliases can solve a lot of things but keeping the golf score low on how many different things need to be setup and customized is also friction.

[Meligy]

How about:

k -> asp
kpm -> apm
kvm -> avm

[glen-84]

@Meligy The tools are capable of working with technologies other than ASP.

[tugberkugurlu]

I would preserve the *pm, *vm as they are very common is other platforms, too. Changing them to nuget, dotnetsdk would confuse A LOT!

[clintkolodziej]

@bitcrazed yeah, they are changing the terminology, rather than kre, which stood for "K Runtime" (where K had no actual meaning) to "Cross-Platform Runtime Environment" or XRE for short (where X is short for Cross), I saw that on the most recent Community Standup run by @shanselman and @DamianEdwards. From previous discussions, as @Alxandr pointed out there were technical/functional hurdles that prevented combining the version manager with the actual runtime command, which is why they were going with dotnet and dotnet-sdk for those two pieces. I'm not a fan of the -sdk part as I mentioned above, I prefer -vm, though I can totally understand why people wouldn't like that either due to vm being short for virtual machine, just my personal preference here as I have worked with a variety of MS and non-MS languages and its more common to see "vm" related to version manager than virtual machine in that context.

[bitcrazed]

@giggio Don't get me wrong - I'm not particularly precious about the vm thing - I'd just rather not see the team introduce a potentially confusing inconsistency into the new platform.

Earlier, you state that:

The whole market already uses vm to define version managers

If *vm is the way several other communities are going then great, but having briefly looked into this, only node and ruby appear to be using *vm suffix for a version management tool/script: Java doesn't (perhaps because they already have a use for 'VM' ;) ). Nor are Python, Perl, Swift, Go, Prolog, Cobol, C/C++, etc. (or at least none that I can find). In fact, pyvm and perlvm both seem to refer to Python and Perl Virtual Machines. But I digress ...

[clintkolodziej]

@davidfowl can probably confirm, but k, kvm, and kpm seem an awfully similar to node, nvm, and npm. Considering that Node is probably the hottest new language at the moment it makes sense to mirror what seems to work for them, at least until the community gives feedback - as we are doing now. Keeping in line with those Node commands may also (hopefully) pull some Node devs over to .NET 2015 by lowering the entrance bar with similar commands, and those who know Javascript will find C# pretty familiar from a syntax perspective -- at least more than Ruby/Python would be.

@bitcrazed mentioned a ton of other languages that don't follow the same pattern for command names, which doesn't surprise me. I think we just need to pick something that makes sense to the majority and would hopefully be familiar to programmers of other languages as well, as luring more devs to the .NET stack is surely a goal of open sourcing the stack.

Anyone have any other suggestions besides -sdk or -vm for this? It seems a matter of preference on those two at this point. Perhaps something like -rm for Runtime Manager?

[Alxandr]

I actually like rm or even rvm, but I don't really like the dash though... And it depends on the prefix. Like, I could totally go with dotnetrm but xrm is hard to swallow. I'd rather go with xvm if x for xre is what we end up with (or I end up aliasing as).

[clintkolodziej]

@Alxandr agreed, I'm not a big fan of the dash either, dotnetrm seems better. I'd be fine with dotnet, xre (called internally by dotnet), xvm (or dotnetrm), and nuget for the suite of commands.

[atrauzzi]

I somewhat like using CLR to inspire names.

clrre
clrvm
clrpm

Added bonus: They're pronounceable and act as introductions to their purpose by not obscuring what's going on. As an outsider, I'm struggling less to understand with those names than any other I've seen so far.

I really think above all else, we need to be consistent with the names.

[glen-84]

I like xrm (X-platform Runtime Manager) the most, or dotnetrm as a second option.

dotnet, xre, xrm, nuget (clean & simple)

I really think that some of you are overly concerned by what Node and Ruby are doing. They are just command names, it's not as if there is some kind of written standard, and I doubt that naming the commands in a certain way would result in more developers moving to .NET.

[GerjanOnline]

dotnet, xre, xrm, nuget (clean & simple)

+1

[atrauzzi]

x is way too generic to make any sense. Saying "this is cross platform" is implicit, you're running it on the platform by that point. It's not a feature that needs to be sold in the executable name. What the command should be doing is describing what is actually running.

Otherwise Mozilla could rename their browser to x - Google could rename Chrome to x - maybe redis should be renamed to x as well, because they're all cross platform...

[glen-84]

@atrauzzi It's not just "x", it's "xr" (X-platform Runtime).

I doubt that the team are going to want to rename the runtime a third time, but what are you suggesting? dotnetre & dotnetrm?

[atrauzzi]

Adding more broad terms doesn't make it more specific. V8 on Chrome is cross platform, and a runtime. Should it be called xr too? NPM runs cross platform, is it xpm? Ruby version manager - xvm? This makes the reason "x" was chosen fairly disingenuous.

My current suggestions are above a few comments, if you wanna check them out. I've shifted a few times based on other peoples' input.

I would hope they're willing to try and find a name that is suitable, not a single cool letter like "x" or "k".

[slang25]

I'm a little confused, in the latest community standup (https://www.youtube.com/watch?v=DNn1cbDJtZI) it seems that dotnetsdk is what it will be, despite the vast majority of feedback being negative on this.

Can someone from Microsoft clarify?

I don't think the name of kvm matters much really, like @DamianEdwards says, it's not something you are going to be typing often, and power users are gonna use aliases. It would be good to know if feedback is still needed on this subject.

[muratg]

As you might have noticed with the recent PRs and check-ins, we have decided to keep the code names for our upcoming Beta 3 release. We are still discussing the final names within the team and we hope to have naming sorted out for the release following Beta 3.

I just wanted to give a quick summary of what we're going with for Beta 3:

• Command line: klr.exe, kpm, kvm, k
• Environment variables: KRE_*
• Folder names in the user profile: .K/packages, .K/runtimes

[giggio]

@muratg is beta3 going to work with vs 2015 ctp 5?

[Eilon]

@giggio there will be a matching VS2015 preview for the ASP.NET 5 beta3 release.

[giggio]

@Eilon Awesome! Tks!

[muratg]

@giggio Yes, you can make it work with CTP5. Like Eilon says It'll also be released with the next VS 2015 preview release and that would be an easier option.

[atrauzzi]

So wait -- they're not being renamed?

[akoeplinger]

@atrauzzi they are, see aspnet/KestrelHttpServer#76 for an example (more details ought to be revealed tomorrow at the next community standup).

[atrauzzi]

I can't wait!

[Eilon]

Yup, on Tuesday's Community Standup https://www.youtube.com/playlist?list=PL0M0zPgJ3HSftTAAHttA3JQU4vOjXFquF we'll talk more about the new naming...

[aligneddev]

in case someone is looking for the new names: http://weblogs.asp.net/imranbaloch/k-kvm-kpm-klr-kre-in-asp-net-vnext.
k.cmd /kl.exe > dnx
kre/xre > dnx
kvm.ps1/.sh > dnvm.ps1.sh
kpm > nuget

[Bartmax]

Thank you @logankd that helps to prepare for next [CTP:RC]/BETA-4