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 https://github.com/aspnet/kvm/issues/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!

[andrexx]

+1 for @anurse suggestions

[congiuluc]

I'd like to rename k simply with dotnet: k -> dotnet kvm -> dotnetvm kpm -> dotnetpm

[tugberkugurlu]

@congiuluc too long to type IMO.

[congiuluc]

@tugberkugurlu Yes it could be a little long but more clear and explicit Obviously we can also abbreviate dotnet with dn: k -> dotnet -> dn kvm -> dotnetvm -> dnvm kpm -> dotnetpm -->dnpm Even if dotnet is cleaner

[tugberkugurlu]

@congiuluc I'm happy with k*, or `d*. dnvm and dnpm are just still too verbose IMO.

[devmondo]

i fully agree with @anurse his abstraction is great, i dont want to use vm,dm, em, etc...

just one alias with commands, it makes it so much easier to remember and use

dotnet run, dotnet upgrade dotnet install dotnet web dotnet alias

plus it goes perfectly with marketing tactics as @shanselman mentioned in the video

and please dont make it aspnet or aspdotnet, because the whole idea now is that it is a new CLR that will run everything and not just ASP.NET

[atrauzzi]

I 100% agree with @clintkolodziej and his suggestion to move all of this technology out from under the ASP.NET branding umbrella. This includes the file->new experience as well. While the naming discussion is of significant importance, I think what he's saying on this should come first. Continuing with the current brand hierarchy is almost guaranteed to be a source of confusion and usage issues because of preconceptions and expectations set out by a system named "ASP.NET".

People are going to be most interested in understanding the difference between old-school .NET and k/roslyn/vNext/ASP.NET 5. See how confusing that is already? How would a job ad for this new technology read so as not to be ambiguous?

---

Out of all the suggestions I've seen for naming and consolidation, I would prefer simply having as few executables as possible:

• dotnet
• [optionally, and if absolutely required] nuget

People will appreciate having a single tool that advises them on best practices and acts as a signpost for possible project-level actions. Multiple commands muddies this and confuses them as to the roles, entry points and approaches involved. Even I find myself still a bit turned around on understanding what everything does.

---

So, with the above mentioned, Microsoft and the community will need to really bring their A-game when documenting just what these tools are in relation to whatever vanilla .NET runtime is installed. Situations where someone tries to install k without a runtime installed may arise and the distinction has to be clear that it compliments .NET, it does not comprise it.

The same goes for what all these k-tools are doing with package management. What is the old tool nuget in relation to things here? Some of this is conflating, especially with the emergence of oneget. I admit, even I'm not 100% clear on the roles and boundaries with package management - let alone package building!

---

The last note I want to mention is that Microsoft and the community should rally behind @directhex and any suggestions he makes. He is probably as far out in the trenches as anyone can be with all the shifts happening in .NET lately. Observations he makes are valuable early indicators of issues that should be remedied before it's too late.

[RickyLin]

I like the current k. It's short and seems more "Linux style". However I'm wondering why it's named "k" other than "d" at the beginning? What does "k" mean? Besides .NET, sometimes I use Ruby in OS X/Linux and feeling very good with Linux terminal commands and utilities. names such as rvm, gem, rake, port are very common in non-Microsoft platform, I think Linux users and OS X users will be happy with k commands and k* can potentially bring more people in Linux and OS X platform to the .NET world. well, it would be much better if we could rename "k" to "d", so it still has all benefits and everyone knows .NET knows what this "d" means.

[atrauzzi]

I don't think you'll find that the linux community likes a command with a single letter for its name. It's extremely ambiguous and as @directhex has outlined, some names by being too short conflict with other commands. Many of which that have existed for decades.

There's also the issue of promoting and evangelizing a tool called "d" or "k". Which will mean absolutely nothing, have zero SEO prospects and just be too vague. These are real considerations that must be made when designing tools that are going to depend on community adoption.

A longer name is fine and if you want a shorter one, you are always free to alias. Forcing everyone to consume the same excessively brief syntax creates more problems than any convenience it adds.

(love your tab key)

[directhex]

"The command is kvm. Except on Debian Linux where it's different" isn't a good look.

See: "node" is "nodejs" on Debian, because an AX.25 Ham Radio app already took Node.

And the Mono class outline viewer "monop" has an active bug against it because BSD took "monop" for a console-based Monopoly clone in 1993.

[RickyLin]

@atrauzzi I must say you are correct.

[stoyandimov]

+1 for the idea of @anurse to merge the k and kvm functionality into dotnet.

I would also suggest nuget as a package manager instead of kpm because having multiple package managers suggests the idea of different package sources. This could confuse developers.

Summing up the above we shrink the command line tools to 2:

• dotnet making perfect sens to .NET developers
• nuget already known to most .NET developers.

[clintkolodziej]

I see a lot of support for combining k and kvm into one command (dotnet) as suggested by @anurse, and leaving kpm alone, but renaming it to nuget. I'm not deeply opposed to any of that, it makes sense - but there are some challenges. As the new .NET is being designed to be cross-platform and open source I think it is valuable to know what all of the other popular open source / cross-platform languages are doing, and what their commands are. With that knowledge hopefully learn what was good or bad on those decisions and improve upon it with .NET 5.

Node commands: node - run code (I saw it is nodejs on debian as something else was already using node) nvm - manage node versions npm - node package manager

Ruby commands: ruby - run code rvm - ruby version manager gem - ruby package manager

Python commands: python - run code ??? - I can't find any standard version manager for python pip - python package manager (ships with python 3.4 from what I see)

Java commands: java - run code ??? - I can't find any standard version manager for java ??? - I can't find any standard package manager for java

Based on the above, it seems there is fair precedent for the package manager to not have the same name/prefix as the run-time command, so using the nuget name would make sense (as long as we can resolve that there is already a nuget.exe on Windows and figure out that conflict).

The run-time I think we already pretty much have consensus that dotnet is the way to go, and if someone really wants a shorter version the capability is already there to make an alias like dnet or d on whatever environment the code is running on. I always prefer shorter commands, as @tugberkugurlu and a few others mentioned, but I'm fine with just creating aliases if everyone else likes the full dotnet command.

The challenge seems to be the approach for what to do with kvm. I kind of like the simplicity of keeping each command separate after thinking about combining the commands for the past day. The benefits that I see are as follows:

1. If k and kvm are combined you would need a run command, which would mean you would have to type dotnet run foo. Of course we could always do some fancy checking in the script for reserved words in the 1st parameter, and run code if it is not a reserved word (ex: run, install, upgrade, etc). The reserved word option would mean you couldn't easily name projects any of those reserved word names, or if you do you would be forced to call them with the run parameter. Normally I wouldn't care too much about that, but build/run/batch scripts would need to be careful to avoid reserved words, or always code the run command. Also as new features are added, I assume new reserved words would also, which could cause complications for existing code/scripts that may have one of the new names.
2. There is already a lot of precedent in the open source world that keeps the version manager separate from the actual runtime command, which could make the transition easier for programmers of other platforms/languages that want to give .NET a try (hopefully they will).
3. I'm not sure if there are any sort of technical complexities or not toward having one command update itself, probably not but it did come to mind.

[atrauzzi]

Just for completeness, here's some updates to your list:

PHP commands: php - run code ??? - version manager (usually not necessary because of strong backwards compat) composer - package and classloader management

Scala commands: scala - Basically runs java with Scala core libraries ??? - version management sbt - package management is incorporated as part of a build process

Also, the Java community is centralizing around gradle which leverages maven.

[davidfowl]

@clintkolodziej you read my mind.

java commands: java - run code ??? - I can't find any standard version manager for java ??? - I can't find any standard package manager for java

maven is the most popular java package manager

Of course we could always do some fancy checking in the script for reserved words in the 1st parameter, and run code if it is not a reserved word (ex: run, install, upgrade, etc). The reserved word option would mean you couldn't easily name projects any of those reserved word names, or if you do you would be forced to call them with the run parameter.

What you mention about reserved words is a concern I also have if we combined kvm and k, it doesn't feel right to me. It does make things simpler though so it's worth a shot.

This bug is also an attempt at removing the k script:

https://github.com/aspnet/KRuntime/issues/1013

The idea being that you can run application's in 2 ways (this already exists today but it's well hidden). You can execute a dll/exe with an entrypoint directly, or you can execute a folder full of code. Basically compiled ahead of time vs compiled on the fly.

[Alxandr]

If aspnet/KRuntime#1013 get's implemented, klr itself could probably be renamed to dotnet. You'd be able to do dotnet myApp.exe which is precisely the same as mono myApp.exe for instance.

I do not like the idea of combining all of the commands into one. Especially since they all work on different technologies.

kvm of today is a PowerShell (or bash on *nix) script. It cannot be a .NET application, because it's used to install the framework, so we can't expect it to already be present.

klr is a native application that laucnes the CLR and does bootstrapping. Though you today (almost) never invoke it directly, k is just a simplified means of adding standard parameters to klr.exe.

kpm install is a managed v5 application, working on top of the klr. Calling kpm basically get's exported to something crazy like klr.exe --appbase /current/working/dir --lib "/path/to/klr;/path/to/kpm" install (or something similar, been a while since I looked at the actual commands).

Also, if I write an app, say something that manages plugins for my system, I would like to be able to use the command install myself for instance. Having to do dotnet /path/to/my/app run install plugin-name doesn't look good.

[clintkolodziej]

@atrauzzi & @davidfowl thanks for the additional info on the java/php/scala commands, it further pushes that keeping a separate package manager (nuget) command is still the way to go.

Also, it doesn't seem that a version manager is completely standard across all the sample languages, but the newer ones generally seem to keep that separate (node/ruby), so it at least wouldn't be a horrible thing to keep the version manager separate from the program launcher.

@Alxandr has a good point, if we kill off the k script and just use the klr.exe directly (renamed to dotnet) then it would pretty much push that kvm would need to be a separate command as it is simply a PowerShell/bash script. The other option would have to be a dotnet script that calls klr.exe (or dotnetlr.exe), which is a similar setup to what we have today. Using a script up front would allow merging k and kvm as was being discussed, but we would still have the klr.exe to decide what to do with.

I'm leaning toward the following:

1. Rename klr.exe to dotnet.exe (or dotnet on *nix)
2. Remove the k script, and change klr to have the nice syntax that the k script provides
3. Keep the kvm script to manage/install different versions of the dotnet.exe executable
4. Keep the kpm script but rename it to nuget
5. Figure out what to do with the existing nuget.exe so it doesn't conflict with point 4.

[csharpfritz]

Regarding the nuget / kpm confusion, we would like to deliver and maintain a single package manager for developers to work with in the .NET framework. Given the history of the NuGet package manager and the number of customers that are already scripted and familiar with NuGet, I expect that name to be used with .NET 2015

Jeff

On Thu, Jan 8, 2015 at 1:08 PM, Clint Kolodziej notifications@github.com wrote:

@atrauzzi https://github.com/atrauzzi & @davidfowl https://github.com/davidfowl thanks for the additional info on the java/php/scala commands, it further pushes that keeping a separate package manager (nuget) command is still the way to go.

Also, it doesn't seem that a version manager is completely standard across all the sample languages, but the newer ones generally seem to keep that separate (node/ruby), so it at least wouldn't be a horrible thing to keep the version manager separate from the program launcher.

@Alxandr https://github.com/Alxandr has a good point, if we kill off the k script and just use the klr.exe directly (renamed to dotnet) then it would pretty much push that kvm would need to be a separate command as it is simply a PowerShell/bash script. The other option would have to be a dotnet script that calls klr.exe (or dotnetlr.exe), which is a similar setup to what we have today. Using a script up front would allow merging k and kvm as was being discussed, but we would still have the klr.exe to decide what to do with.

I'm leaning toward the following:

1. Rename klr.exe to dotnet.exe (or dotnet on *nix)
2. Remove the k script, and change klr to have the nice syntax that the k script provides
3. Keep the kvm script to manage/install different versions of the dotnet.exe executable
4. Keep the kpm script but rename it to nuget
5. Figure out what to do with the existing nuget.exe so it doesn't conflict with point 4.

— Reply to this email directly or view it on GitHub https://github.com/aspnet/Home/issues/261#issuecomment-69221769.

[spboyer]

+1 to @clintkolodziej most recent entry, and i'd like to toss out an option to the nuget name issue. @davidfowl may appreciate -- thoughts on using nupkg ? pronounced "nup keg" as the command line for the package manager.

Then there is dotnet and nupkg with no conflict with nuget.exe

[clintkolodziej]

@spboyer nupkg would be a good option, +1 to that if the nuget.exe is a conflict that cannot be resolved. As @davidfowl suggests: NUP-KEG.

[glen-84]

@clintkolodziej You still need to rename kvm to at least get rid of the "k". I don't like the "vm" either, although it seems like Node & Ruby are using this already, and I can't really think of an alternative.

dotnetvm, dnvm, or dvm I guess.

[directhex]

Why "vm" anyway? It's more of a language runtime than a VM, unless someone integrated with QEMU without telling me. If the "K" has to stay, why not an "lr" suffix for "language runtime"? Isn't "CLR" a thing in .NETland?