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”?

[glen-84]

@directhex VM = Version Manager, it's not the runtime itself.

Edit: The fact that you got confused just supports what I said yesterday, but what alternatives are there for "version manager"?

[directhex]

Is it meaningful? "K Version Manager". Okay, what's "K"? Google says... Kellogg Company, whose stock price is rising. Or the 4chan board about tanks, guns and knives. Do those need versions managing? This ties into https://github.com/aspnet/Home/issues/261#issuecomment-69180228 - what is the product? What's the brand? What will people be googling? Or binging in here, I guess...

[glen-84]

@directhex That is the whole point of this issue, to replace the "K". The brand is ".NET" (dotnet).

[Bartmax]

I think the problem with reserved words can easily be fixed with prefix character for invoking other tools not commands.

Let's say we have : dotnet dotnet-vm dotnet-pm (or dotnet-nuget)

invoking dotnet -vm will use dotnet-vm and dotnet -pm will invoke dotnet-pm no other "reserved" words needed.

This will indeed keep all tools separate and then you can alias.

That leaves us with: rename klr to dotnet (implementing aspnet/KRuntime#1013) rename kvm to dotnet-vm rename kpm to dotnet-pm or dotnet-nuget or nuget (dependin on nuget.exe conflict)

and then creating corresponding aliases and (optionally) support dotnet -vm and dotnet -pm

[clintkolodziej]

@glen-84 for the kvm rename I agree - I forgot to include that in my last post - it would be something more like dotnetvm or dnvm, etc. I don't have a strong preference there either way, but dotnetvm may make more sense for those new users, and advanced users know enough to be able to make a shorter alias.

[yaakov-h]

If you look at the examples above for other languages and frameworks, none of them follow the pattern that some people seem to be trying to enforce here.

Runtime: ruby Version Manager: rvm Package Manager: gem

Note that it isn't rubyvm or rubypm. The names don't have to share a common prefix.

.NET already has a package manager - nuget, and AFAICT kpm uses NuGet packages (even kvm uses NuGet packages), so I'm in favour of renaming kpm to nuget if possible.

However, I don't think dotnetvm, dotnetsdk or dotnet-vm are reasonable names.

I also don't agree with pre-standardising on aliases. Different users have different preferences and may have their own conflicts to worry about. IMO, .NET should provide one set of names, and users can alias them to whatever they want, should they choose to do so.

Here's another idea: If the runtime is a nuget package, why not install it with nuget or kpm commands? Why have kvm act as a faux-nuget frontend?

[atrauzzi]

I like your last question. Why is kvm doing package stuff?

[Alxandr]

@atrauzzi

It's not really. The reason is quite simple, the KREs are packaged as nuget packages and distributed over myget. However, it does no dependency resolution and all that stuff (at least it didn't last I read the sources). It sends a http request to a static source url to get the latest version number, and then another one to download that version, and it unpacks it. The folder could easily be named something else than "packages" (and probably should imho).

[Alxandr]

@yaakov-h

kpm runs on the runtime that kvm installs. It's like requiring windows to install newer versions. This works fine for already configured/set up computers, but if you ever format you'r fucked. kvm needs to work on a machine that doesn't even have mono/CLR, because when dealing with .NET Core, you might not want those, and currently kvm is the way to get .NET Core.

[clintkolodziej]

@yaakov-h:

I think kvm isn't really as necessary for installing new versions - I'm sure nuget could probably be made to do that (someone more familiar with the inner workings should comment on that). I do think kvm is more for managing which of the many versions is being used at a given time than installing them. With the assumption that kvm is still necessary as a separate command I don't think it necessarily needs to have to begin with dotnet either, though we do need something that people can reasonable understand is related to .NET - if that is dvm, dnvm, dotnvm, dotnetvm I don't think it really matters. What matters most is the runtime name, second would be the package manager, and third probably the version manager. To be honest most people may never use kvm until it is time to upgrade, as most people will install it once and use whatever the current release is at the time - they won't be working off of daily builds.

Agreed as well on pre-standardized aliases, if the runtime is dotnet and I think it is too long I can alias it myself, to whatever I like. The same goes for the kvm, if it is dotnetvm and I don't like it I can create an alias to whatever I do like that isn't a conflict on my system. I think for the most part nuget is probably safe.

[clintkolodziej]

@Alxandr good info, I just looked, kpm.cmd just bootstraps Microsoft.Framework.PackageManager, so if kvm.ps1 didn't do the installation of KRE then kpm.cmd wouldn't have anything to load the first time you run it (unless the initial installer of all of these commands brought down an initial version of the libraries).

[Alxandr]

@clintkolodziej kvm can't be "baked into nuget", cause nuget doesn't work if you have no .NET runtime installed...

[clintkolodziej]

@Alxandr agreed, I didn't realize that until I looked more at the logic in the actual commands

[atrauzzi]

kvm might be fine as a separate tool because I don't forsee people using it often. Ideally it would be nice if people could get started with the whole ecosystem knowing only about nuget and dotnet.

[Alxandr]

Probably, what 98.735% of the debt are going to use is VS. Meaning for them this discussion in itself holds no meaning. The just go vs - > run, and nuget ui, and it just works.

For the next few years mostly weird hipsters, who has actually looked at a cmd script the last month, and runs builds that are straight off the CI press will be using these commands. And we'll be all like, but the commands are so much simpler than the ui, and they'll be all like, but the ui is so much easier than the commands. And we'll just stare at each other and feel pitty for the other party that are obviously doing it wrong.

Point is, kvm is for hipsters. Most hipsters care more about the fact that it's easy to type, rather than a name that makes sense. My vote goes to dnvm, dotnet and dnpm.

I would also suggest building the version manager on top of node, instead of on top of PowerShell.today there's 2 separate implementation of version manager and they have to be kept in sync with each other. Microsoft already have several other command line utilities, like the Azure CLI. Given that diversion manager is a rather simple script, it should be fairly straightforward to implement a node utility that can work on all platforms, this would also make it easier to interact with the version manager from code.

[atrauzzi]

@Alexandr - Good thinking. There should be no powershell going on in these projects.

I go between command line and GUI FWIW. I should think part of the changes going on with .NET here are to make it appealing to new audiences.

[yaakov-h]

@Alexandr Anyone developing on OS X or Linux is going to need to know these commands.

Is Mono still required to install on non-Windows platforms, or has that requirement gone away? Because if you still need a prereq in order to install .NET, then there's no advantage in keeping kvm as a fairly dependency-less script and it could be a .NET-based utility.

I disagree on: node utility that can work on all platforms .NET shouldn't require any other platforms to install and run except a typical OS and userland stack. I shouldn't have to install Node, Java, Scala, Ruby, PHP or anything else in order to install .NET.

Powershell is now standard on Windows and sh or bash is standard on most *nix systems (embedded systems excluded). Anything else would require installing a new interpreter/compiler, or providing native code - none of which I'm in favour of.

[tmek]

Put it all behind "dotnet" with a "dn" alias.

This gives users a single point of entry (dotnet --help) for discovering all sub commands and options.

examples: .net runtime environment: dn assembly/command [options] .net package manager: dn -pm [package manager options] .net version manager: dn -vm [version manager options]

[glen-84]

I shouldn't have to install Node, Java, Scala, Ruby, PHP or anything else in order to install .NET.

+1

A native binary, or shell scripts if that's too difficult.

[panesofglass]

I'm fully in agreement with @Alxandr.

WRT nuget, I don't think nuget is the right tool for the job. I think a better solution would be to provide a meta package manager that could be used to run against all the relevant package managers used in the ASP.NET these days, including nuget, bower, and npm. This is similar to the multiple sources provided by chocolatey/OneGet.

[panesofglass]

WRT aliases, since aliases are so simple to create (at least in PowerShell) should aliases be provided out of the box? We are talking about three to five characters in most cases. Will that really make a difference?

[benaadams]

Don't mind on name. but make sure it is something unique/searchable in your favourite search engine, pit of success and whatnot; for example "go" was a terrible name for a search engine company to come up with due to its everyday use, hence this and other reasons is often referred to as golang, c# as csharp and c++ as all sorts of things.

dotnet by itself would lesser but similar issues as it refers to the whole ecosystem; and with it a full history of dotnet things.

So if you were trying to find out what was going wrong with this particular invoker; learning, finding command options etc it would just make it harder as it would need qualifiers e.g. "dotnet command" or "dotnet exe", but even that would get confused with info on writing dotnent command line programs, or even the thing you are creating rather than what you are using.

It can't be too long as then people will alternate between using an alias and the full name, so information will become fragmented on search terms.

One letter on the end of dotnet would be enough to make it unique, though generally becomes weird: e.g. dotnete (enviorment/execute), dotnetr (run)

Could go powershell style and use hyphens as suggested by @Bartmax : e.g. dotnet-run, dotnet-pm, dotnet-vm

Also dn doesn't seem a particular used set of two letters for something shorter.

[GerjanOnline]

I think everyone agrees that the kre (and k) should become dotnet. It just seems logical and in line with mono (dotnet foo.exe, mono foo.exe).

I also like the abstraction that @anurse proposed: dotnet use 1.0.0 dotnet run dotnet install dotnet list

But I can see that here are some technical challenges / obstacles as mentioned above. If this is not possible it would go for:

dotnet dotnvm dotnpm

I'm also not liking dotnetsdk, same reason as @clintkolodziej

[nvivo]

After a lot of reading, I'm convinced the first idea of @anurse as described here is the best idea.

I vote against aliases. dotnet is small and simple enough.

[kbulte]

I agree with @anurse on the first two:

• k -> dotnet
• kvm -> dotnet

Based on nuget.org which says: "Nuget is the package manager for the Microsoft development platform including .NET" So I think it should be Nuget or it's fomer name NuPack:

• kpm -> nuget or nupack

[0x5487]

I'd vote for @anurse 's idea. That is the best one so far.

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

[burtonrodman]

+1 dotnet and nuget

[clintkolodziej]

+1 dotnet and nuget with the following concerns. I'm fine if kvm (renamed of course) was a separate command, but most agree it is cleaner from a user standpoint to combine them, which makes sense.

1. From above there was as KRuntime issue mentioned by @davidfowl to remove the k script and rename klr.exe appropriately (and clean up the parameter syntax), which we are suggesting is renamed to dotnet. Since this command will be a native app I want to ensure that combining the kvm script logic into the current klr.exe code is feasible considering all of that logic needs to be cross platform compatible (kvm is currently not native code). My concerns are that paths might be different, which is easy to handle when there is a separate kvm powershell script for windows, and a shell script for *nix. Also it would need confirmation that managing versions of a runtime from a program that is running on that runtime (not a script) doesn't cause any technical hurdles. I'd imagine not, but I haven't read too much of the KRuntime source to know what is going on there.
2. As mentioned a few times above, there is also an existing nuget.exe that we'd be conflicting with, unless of course that is renamed, or all of the functionality of both are combined. I'd imagine this would need feedback from the Nuget team, which I have no idea if they are in the same organizational structure as the ASP.NET team, hopefully someone from that team can comment.

Also, realizing re-architecting all of ASP.NET from scratch is a monumental task, if bandwidth isn't available to combine klr.exe, k, and kvm, does anyone have a better idea of what to call the version manager for the dotnet command, as that code is already written. I think we have pretty much reached consensus that dotnet and nuget are the ideal names for the launcher and package manager.

[csharpfritz]

Re: Renaming to NuGet

We are in the same organization, and I like the way you're thinking.

Jeff

-----Original Message----- From: "Clint Kolodziej" notifications@github.com Sent: ‎1/‎16/‎2015 16:48 To: "aspnet/Home" Home@noreply.github.com Cc: "Jeffrey T. Fritz" jeffreytfritz@gmail.com Subject: Re: [Home] CommunityStandup: Can we rename K? (#261)

+1 dotnet and nuget with the following concerns. I'm fine if kvm (renamed of course) was a separate command, but most agree it is cleaner from a user standpoint to combine them, which makes sense. From above there was as KRuntime issue mentioned by @davidfowl to remove the k script and rename klr.exe appropriately (and clean up the parameter syntax), which we are suggesting is renamed to dotnet. Since this command will be a native app I want to ensure that combining the kvm script logic into the current 'klr.execode is feasible considering all of that logic needs to be cross platform compatible (kvmis currently not native code). My concerns are that paths might be different, which is easy to handle when there is a separatekvm` powershell script for windows, and a shell script for *nix. Also it would need confirmation that managing versions of a runtime from a program that is running on that runtime (not a script) doesn't cause any technical hurdles. I'd imagine not, but I haven't read too much of the KRuntime source to know wh at is going on there. As mentioned a few times above, there is also an existing nuget.exe that we'd be conflicting with, unless of course that is renamed, or all of the functionality of both are combined. I'd imagine this would need feedback from the Nuget team, which I have no idea if they are in the same organizational structure as the ASP.NET team, hopefully someone from that team can comment. Also, realizing re-architecting all of ASP.NET from scratch is a monumental task, if bandwidth isn't available to combine klr.exe, k, and kvm, does anyone have a better idea of what to call the version manager for the dotnet command, as that code is already written. I think we have pretty much reached consensus that dotnet and nuget are the ideal names for the launcher and package manager. — Reply to this email directly or view it on GitHub.=

[panesofglass]

Merging all-the-things into a single command line tool makes me nervous. In particular, I worry about breaking changes that may be desired for one set of consumers that is unnecessary for another set and just creates continued pain.

Most users are going to use one or a few of these things, and a top-level script coordinating and orchestrating will provide exactly what they need. Then you leave the single-purpose CLI tools for dev ops folks to target their specific needs without having to learn how to manage a single, large CLI tool.

You could easily create a dotnet.ps1 and dotnet.sh for coordinating the other command line tools, which in the case of nuget will likely include things such as npm and bower, to name a few. Likewise, it seems strange to me to puff up version management with the simpler klr.exe that could focus on its own, specific commands.

[clintkolodziej]

It begins:

kvm: https://github.com/aspnet/kvm/issues/137

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

kpm: don't see anything yet here

[peterblazejewicz]

:clap: :+1:

[atrauzzi]

@davidfowl @shanselman - Out of curiosity, will all the vnext/k tech still be falling under the ASP.NET banner, or is there a plan to brand it as more general purpose under .NET? ( https://github.com/dotnet )

[nvivo]

@atrauzzi good question.

With corefx being under dotnet, I wonder why k would remain here.

[Eilon]

@atrauzzi @nvivo not quite sure yet exactly where some of this will end up. For example, even EF7 right now is under aspnet, but it's of course much broader than just ASP.NET. The only reason the things are the way they are right now is that there was nowhere else to put them. But I expect in the future things will fall into their natural places. I just couldn't say when.

[atrauzzi]

Another thought that just occurred to me as part of these changes... Wouldn't it be better to use dotnet.json as opposed to the rather ambiguous project.json?

[davidfowl]

Could be, but that doesn't matter as much, and doesn't have to match. Some examples:

• maven - pom.xml
• npm - packages.json
• nuget (current) - packages.config
• bundler - gemfile

etc

It could be called nuget.json for all we know :smile: but it'll remain project.json for now.

[atrauzzi]

For the record, I'm no fan of other systems that use too generic a name as well. Which is mainly why I'm suggesting this here.

Should I create a ticket somewhere just so the idea doesn't get forgotten?

[andoband]

What does the sdk part stand for in dotnetsdk? Software development kit?

If that is true, in my understanding of what the dotnetsdk is (as set of command line utilities to manage the version of .Net that is used), SDK makes sense in only a very general sense of the term. In my experience I've seen SDK used to label a batch of libraries, utilities and docs. Is that what dotnetsdk is?

[clintkolodziej]

@andoband dotnet-sdk is the new name for kvm, which manages which version of the .NET 2015 Cross-Platform Runtime Environment (XRE) is installed/selected. I'm not a huge fan of the name as I tend to associate (as you also mentioned) SDK as a large download of libraries/utilities/documents, as below for Azure and Windows SDK's. kvm is more of a runtime version manager and not an SDK in my mind. In any case I'll just alias it to something I like if they keep that name, though as @DamianEdwards mentioned in the last Community Standup video it likely will only be used for bleeding-edge developers that always want the newest XRE, or more likely around the time that the next .NET vNext is being tested so you can plan around with alpha/beta bits (as we are doing now).

Azure SDK: http://azure.microsoft.com/en-us/downloads/archive-net-downloads/

Windows SDK: http://www.microsoft.com/en-us/download/details.aspx?id=8279

[bitcrazed]

Personally, as it starts to open-up the CLR and .NET to open-source communities, I wish Microsoft would start focussing more on the CLR, than on .NET: .NET is really a collection of frameworks that are combined with developers' code and bundled into package(s) that are executed by a CLR-aware host.

Unfortunately, .NET as a brand carries with it a great deal of baggage, much of it neutral/negative, especially in non-Microsoft (and particularly in anti-Microsoft) communities.

However: 1) The CLR remains relatively untarnished 2) The CLR is an open standard (http://www.ecma-international.org/publications/standards/Ecma-335.htm) 3) The CLR is REALLY what we're talking about here, not .NET, the framework

I also dislike the *vm suffix for version manager - 'VM' is already a widely used term referring to virtual machines and I think it wise to avoid ambiguity where possible.

While I understand the need to separate the runtime engine command from versioning/package management concerns, I am not sure of the benefit of separating versioning and package-management. Why not combine the two?

Combining the above, I believe it would be beneficial for the current 'k' command-line tooling & folders to be renamed as follows:

k --> clr kvm --> clrpm (or clrver/clrversion if kpm MUST be separated) kpm --> clrpm

.kre --> .clr .kpm --> .clrpm

[giggio]

The whole market already uses vm to define version managers. rvm, nvm, etc. It makes no sense to use dotnet IMHO, it will be confusing to people coming to ASP.NET from other technologies. You do somethingvm, people will already know what it is. Don't we have xre? Why not xvm?

[panesofglass]

@bitcrazed I had thought the same thing but didn't see anyone appearing to take that approach. I'm with you, though.

[clintkolodziej]

@giggio @bitcrazed If kre->xre and k->dotnet I'd be equally ok with xvm or dotnet-vm (or provide both as out-of-the-box aliases. Since the version manager relates more to the XRE than it does to the command to "run" a program xre and xvm would be a good pair.

I agree, "vm" is a pretty well established naming convention for version managers of open-source languages, though I could see those who haven't used ruby or node may see "vm" and assume it means Virtual Machine. The node and ruby folks (in my opinion) may be a key population who may be interested in checking out the new open-source dotnet, as having one of the big-three tech companies supporting it will give it a lot of sway for people to use it in production scenarios - which is one place node is struggling (which resulted in io.js). <-- Not trying to start a flame war, just commenting that a lot of people were waiting for node 1.0 to be released before using it in production, there are certainly a lot of websites using the current version of node in production with no issues.

[bitcrazed]

I agree that in some communities, the term VM is used to describe Version Manager, but outside of those communities, VM refers to Virtual Machine. Just type VM into Google/Bing and see how many pages you have to scroll through until you find any mention of a version manager. Heck, on Google, I find 'VolleyBall Online Manager' before I find any mention of version manager ;)

Question to the ASP.NET team: Why do we need to separate Version Manager and Package Manager? Couldn't they be combined?

clrpm use coreclr 1.0.1 clrpm update packages clrpm install package TimeForAPint

[bitcrazed]

@clintkolodziej @shanselman XRE? Seriously?

So now we have my code running with/on .NET Framework atop the Common Language Runtime which runs on the X-platform Runtime Engine?

[glen-84]

@andoband,

I agree, I posted the following on YouTube:

I like "dotnet" and "nuget", but I'm not so sure about "dotnetsdk" (the "sdk" part in particular). "Kit"
implies a set of "things" (binaries, documentation, samples, etc.), whereas this is a single tool with a
specific purpose. What about "dotnet-rvm"? (RVM=Runtime Version Manager)?

... but I didn't realize that "RVM" is used by Ruby, so here are some other ideas:

dotnetv     (.NET Version, f.e. "dotnetv install ...")
dotnetvu    (.NET Version Utility, could be pronounced ".NET view")
xrem        (X-platform Runtime Environment Manager)
xrevm       (X-platform Runtime Environment Version Manager)
xrevu       (X-platform Runtime Environment Version Utility)

Avoiding "vm" would be nice, but might not be easy.

I don't really like "xvm", because it would stand for "X-platform Version Manager" -- what is "X-platform"? It's managing versions of what? It should mention .NET or the runtime environment IMHO.

[Bartmax]

oh! this https://github.com/aspnet/XRE is new to me! what a mess :D

On Fri, Jan 23, 2015 at 8:42 PM, glen-84 notifications@github.com wrote:

@andoband https://github.com/andoband,

I agree, I posted the following on YouTube:

I like "dotnet" and "nuget", but I'm not so sure about "dotnetsdk" (the "sdk" part in particular). "Kit" implies a set of "things" (binaries, documentation, samples, etc.), whereas this is a single tool with a specific purpose. What about "dotnet-rvm"? (RVM=Runtime Version Manager)?

... but I didn't realize that "RVM" is used by Ruby, so here are some other ideas:

dotnetv (.NET Version, f.e. "dotnetv install ...") dotnetvu (.NET Version Utility, could be pronounced ".NET view") xrem (X-platform Runtime Environment Manager) xrevm (X-platform Runtime Environment Version Manager) xrevu (X-platform Runtime Environment Version Utility)

Avoiding "vm" would be nice, but might not be easy.

I don't really like "xvm", because it would stand for "X-platform Version Manager" -- what is "X-platform"? It's managing versions of what? It should mention .NET or the runtime environment IMHO.

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

[Alxandr]

@bitcrazed (using the old names here for simplicity) kvm is a console script (powershell on windows, bash on *nix) that is used to install (and select) kres. This is mainly important if you have a new machine, because how are you going to install something that requires itself to install it? kpm is running on the CLR (it's basically a NuGet stripped down client with custom commands). So you can't use it to install the klr, because it runs on the klr. Thus you either need separate commands, or a console script that does a lot of magic keyword routing to different programs.

[bitcrazed]

@Alxandr Thanks for the clarification - I guess the split between KVM and KPM makes sense then.

Still prefer clr* to dotnet* though - FAR less typing ;)

clrvm - I guess that's fine if vm ends up being the blessed (albeit potentially confusing) suffix.