Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support changing the default language #4224

Open
isaacabraham opened this issue Jan 25, 2020 · 17 comments
Open

Support changing the default language #4224

isaacabraham opened this issue Jan 25, 2020 · 17 comments
Milestone

Comments

@isaacabraham
Copy link

@isaacabraham isaacabraham commented Jan 25, 2020

I would like to be able to default the dotnet sdk language to F#. Currently we have to remember to put -lang F# with all standard project templates. I would like to be able to set a global flag that changes the default to F#.

@aspnetde

This comment has been minimized.

Copy link

@aspnetde aspnetde commented Feb 7, 2020

Yes, please!

@baronfel

This comment has been minimized.

Copy link

@baronfel baronfel commented Feb 7, 2020

Earlier in the dotnet SDK lifecycle this was supported, and it was wonderful. This is one of those death-by-1000-cuts issues that don't impact the mainstream but when they do hit are very annoying.

@TimurZanagar

This comment has been minimized.

Copy link

@TimurZanagar TimurZanagar commented Feb 7, 2020

Would be great!

@eiriktsarpalis

This comment has been minimized.

Copy link
Member

@eiriktsarpalis eiriktsarpalis commented Feb 8, 2020

Would be nice to see this added back.

@jdh30

This comment has been minimized.

Copy link

@jdh30 jdh30 commented Feb 8, 2020

Yes.

@uzochiapa

This comment has been minimized.

Copy link

@uzochiapa uzochiapa commented Feb 8, 2020

Yes. This will be awesome.

@LukeBurgessYeo

This comment has been minimized.

Copy link

@LukeBurgessYeo LukeBurgessYeo commented Feb 10, 2020

Yes please.

@forki

This comment has been minimized.

Copy link

@forki forki commented Feb 10, 2020

A recommendation from Twitter was to use global.json. That file is already used to determine the sdk version and you can put it in the root of your or in the root of a project.

@0xaryan

This comment has been minimized.

Copy link

@0xaryan 0xaryan commented Feb 11, 2020

I barely create new C# projects nowadays and all my new dotnet projects are in F#. Yes please, I want this!

@forki

This comment has been minimized.

Copy link

@forki forki commented Feb 12, 2020

As a follow up from the Twitter discussion. So far the global.json is only read in the step that decides which sdk version to use. Not in the dotnet new command itself. Maybe it would be possible to convert such values in global.json into environment variables for the spawned processes. So dotnet new and all other commands would not need to read the global.json again.

@dasMulli

This comment has been minimized.

Copy link
Contributor

@dasMulli dasMulli commented Feb 12, 2020

Local tools use a .config/dotnet-tools.json. There could be a .config/dotnet-new.json which could then be recursively searched.

do note that MSbuild also alreeady used global.json for other things (MSBuild SDK versionos) which also affects VS for non-.net core projects so the ideaof having it for SDK resolution only was already made impossible.

@enricosada

This comment has been minimized.

Copy link
Contributor

@enricosada enricosada commented Feb 13, 2020

Another option (smaller implementation but more specific, less bikeshedding) is to use an env var.

That allow a global per user configuration.

I think the dotnet new is something really useful for developers as cli.
IDE/editor have their way to specify a default preference.
To be scripted programmatically the -lang param should be always passed to be safe

A possible implementation (require rebase) is done in an old PR dotnet/cli#5679

Having that env var doesn’t prevent a more comprensive .netconfig file later, when there is an agreement on this bigger scope

Using current global.json I think is not correct, because current behavior is to stop at first found, so cannot do a shared per user atm.
Another option is allow a per user global.json where I can specify that preference and is always loaded (overrriden by repo specific global.json).
Like other tools, a config file in user folder. Maybe call it .net :)

@toburger

This comment has been minimized.

Copy link

@toburger toburger commented Feb 14, 2020

+1 for the env var

@khellang

This comment has been minimized.

Copy link

@khellang khellang commented Feb 16, 2020

I remember filing this issue a few years ago... 🙈 #4950

@enricosada

This comment has been minimized.

Copy link
Contributor

@enricosada enricosada commented Feb 18, 2020

I remember implementing it twice few years ago, one for project.json dotnet new ( sdk < 1.0) and one for dotnet new based on .NET Templating ( sdk >= 1.0 ) who were based on different templating engines.

It got sidetracked waiting for the user config file (and the inevitable bikeshedding) :( but that's something understandable who happen in development often

Anyway, i rebased and sent the PR #10666 here targeting latest master
But i think this repo mean sdk 5.x

It will be awesome if we can have it in the LTS also, so next sdk 3.1.200.
So i sent also PR dotnet/cli#13237 to pull it in .NET Core Sdk 3.1.2xx
I think dotnet/cli it's the right repo for 3.1.2xx released but dunno with dotnet/toolset and dotnet/sdk, so happy to rebase as needed

As a note, the env var can be temporary, until a config file or whatever exists.
To continue having the env var after the config file exists, is not that much maintenance either, so low risk

@dasMulli

This comment has been minimized.

Copy link
Contributor

@dasMulli dasMulli commented Feb 18, 2020

If only we had a config system that could pull values from ENV but also would be able to use files as well.. oh yeah Microsoft.Extensions.Configuration 😄

if a .netconfig or similar is going to happen, i'd be all for a way to specify various SDK / CLI / * configs in a way that would be simlar to ASP.NET Core configuration. While i'm not such a huge fan of the syntax, something like NETSDK_Templating:DefaultLanguage (or __ instead of :) would feel naturally in the m.e.configuration world and we would all know (or be able to learn) what the JSON / XML / * equivalent would be.

@nguerrera nguerrera added this to the 3.1.3xx milestone Feb 24, 2020
@cartermp

This comment has been minimized.

Copy link

@cartermp cartermp commented Feb 24, 2020

Just to communicate a discussion that we had about this:

The proposed solution by @enricosada is good for now. We do want to design and build a long-term configuration solution that won't rely on environment variables (which @enricosada mentions!). We can't guarantee that it would make it for .NET 5, so we'll try to move forward with the environment variable in the interim. Once there is a long-term solution in place, we'll ask folks to use that instead, and we'll cease support for the environment variable (even though it may continue to work in the future).

Thanks @enricosada for the proposed change 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.