From 1d4305f085e2910b817a581c529aea9f67589cda Mon Sep 17 00:00:00 2001 From: Shahrukh Khan Date: Fri, 30 Apr 2021 21:37:03 -0500 Subject: [PATCH 1/5] Add rfc template --- rfcs/0003-languages.md | 59 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 rfcs/0003-languages.md diff --git a/rfcs/0003-languages.md b/rfcs/0003-languages.md new file mode 100644 index 0000000..2e32ebe --- /dev/null +++ b/rfcs/0003-languages.md @@ -0,0 +1,59 @@ +--- +feature: (fill me in with a unique ident, my_awesome_feature) +start-date: (fill me in with today's date, YYYY-MM-DD) +author: (name of the main author) +co-authors: (find a buddy later to help out with the RFC) +shepherd-team: (names, to be nominated and accepted by RFC steering committee) +shepherd-leader: (name to be appointed by RFC steering committee) +related-issues: (will contain links to implementation PRs) +--- + +# Summary +[summary]: #summary + +One paragraph explanation of the feature. + +# Motivation +[motivation]: #motivation + +Why are we doing this? What use cases does it support? What is the expected +outcome? + +# Detailed design +[design]: #detailed-design + +This is the core, normative part of the RFC. Explain the design in enough +detail for somebody familiar with the ecosystem to understand, and implement. +This should get into specifics and corner-cases. Yet, this section should also +be terse, avoiding redundancy even at the cost of clarity. + +# Examples and Interactions +[examples-and-interactions]: #examples-and-interactions + +This section illustrates the detailed design. This section should clarify all +confusion the reader has from the previous sections. It is especially important +to counterbalance the desired terseness of the detailed design; if you feel +your detailed design is rudely short, consider making this section longer +instead. + +# Drawbacks +[drawbacks]: #drawbacks + +Why should we *not* do this? + +# Alternatives +[alternatives]: #alternatives + +What other designs have been considered? What is the impact of not doing this? + +# Unresolved questions +[unresolved]: #unresolved-questions + +What parts of the design are still TBD or unknowns? + +# Future work +[future]: #future-work + +What future work, if any, would be implied or impacted by this feature +without being directly part of the work? + From 3664cedcff6e74966f465ca197ac6a3719e2ee51 Mon Sep 17 00:00:00 2001 From: Shahrukh Khan Date: Sat, 1 May 2021 02:05:49 -0500 Subject: [PATCH 2/5] Continue adding rfc --- rfcs/0003-languages.md | 148 ++++++++++++++++++++++++++++++++++------- 1 file changed, 124 insertions(+), 24 deletions(-) diff --git a/rfcs/0003-languages.md b/rfcs/0003-languages.md index 2e32ebe..37ef82a 100644 --- a/rfcs/0003-languages.md +++ b/rfcs/0003-languages.md @@ -1,59 +1,159 @@ --- -feature: (fill me in with a unique ident, my_awesome_feature) -start-date: (fill me in with today's date, YYYY-MM-DD) -author: (name of the main author) -co-authors: (find a buddy later to help out with the RFC) -shepherd-team: (names, to be nominated and accepted by RFC steering committee) -shepherd-leader: (name to be appointed by RFC steering committee) -related-issues: (will contain links to implementation PRs) +feature: (languages) +start-date: (2021-04-30) +author: (Shahrukh Khan) +related-issues: (None) --- # Summary [summary]: #summary -One paragraph explanation of the feature. +This RFC describes how language support is to be implemented in Soxin. This +breaks down in two areas: + +* How languages are defined, i-e how to define the language and its properties + i-e its compiler, tools, editor plugins etc. How the user can define the + defualt plugins for a language in his editor(s). +* How the user can select default set of languages and its required tools in + his editor, and how to override default settings on the editor. # Motivation [motivation]: #motivation -Why are we doing this? What use cases does it support? What is the expected -outcome? +As Soxin is aimed at providing its users with easy-to-configure software, while +allowing for great customization, an RFC describing how such an important +feature integrates with the project was needed. # Detailed design [design]: #detailed-design -This is the core, normative part of the RFC. Explain the design in enough -detail for somebody familiar with the ecosystem to understand, and implement. -This should get into specifics and corner-cases. Yet, this section should also -be terse, avoiding redundancy even at the cost of clarity. +## Language definition + +Languages would be defined in a module named `soxin.programming.languages`. +Each language, would be an attribute set in this module: + +``` +soxin.programming.languages = { + go = { /* ... */ }; + java = { /* ... */ }; + python = { /* ... */ }; +} +``` +## Tools defination + +Programming tools will be defined in a module named `soxin.programming.tools`. +Each tool will be an attribute set in this module. + +``` +soxin.programming.tools = { + git = { /* ... */ }; + tmux = { /* ... */ }; +} +``` +This allows soxin to define its own support for languages and tools, while +allowing room for user customization as well. + +Similar to RFC 2, each programming language must include a key for each editor +which will support that language. For instance, it could be a plugin for that +editor that installs support for that language, plus some extra configuration +to configure that plugin. + +## User interaction + +### Globally + +Similar to RFC 2, a `soxin.settings.programming.languages` and +`soxin.settings.programming.tools` option would be introduced to allow the user +to choose his programming stack. The only permitted values here shall be the +defined in `config.soxin.programming.`. This option shall be of type +`Array` of `str`, with apply function which iterate over the array and find +appropriate language or tool. + +### Per-editor + +Each editor that supports a language must provide a +`soxin.programs..language` and `soxin.programs..tool` +option to allow the user to override the programming stack settings per editor. +These options will default to `config.soxin.settings.programming.`, +and thus will be of type `attrs`. Similar to RFC 2, they will also have will +also allow `str` and have an `apply` function that will lookup the theme +from `config.soxin.programming.` for each option. + +# Examples and Interactions +[examples-and-interactions]: #examples-and-interactions + +Here's how one could define a language and a tool implementing only the `neovim` +editor: + +``` +{ pkgs, ... }: + +{ + config.soxin.programming.languages = { + go = { + neovim = { + plugins = [ pkgs.neovim.go ]; + extraRC = '' + ''; + }; + }; + + config.soxin.programming.tools = { + git = { + plugins = [ pkgs.neovim.fugitive ]; + extraRc = '' + ''; + }; + }; + }; +} +``` + +Here's how this would be implemented on the editor side: + +``` +{ config, lib, ... }: + +let + cfg = config.soxin.programs.neovim; + goSupportRc = cfg.programming.languages.go ? ""; + gitSupportRc = cfg.programming.tools.git ? ""; + goSupportPlugins = cfg.programming.languages.go.plugins ? []; + gitSupportPlugins = cfg.programming.tools.git.plugins ? []; +{ + config.program.neovim = lib.mkIf soxin.programs.neovim.enable { + enable = true; + configure = '' + /* Some configuration */ + ${goSupportRc} + ${gitSupportRc} + ''; + + plugins = [ /* Some plugins */ ] ++ goSupportPlugins ++ gitSupportPlugins; + }; +} +``` + +The options of the `programs.neovim` have been modified for simplicity's sake. + # Examples and Interactions [examples-and-interactions]: #examples-and-interactions -This section illustrates the detailed design. This section should clarify all -confusion the reader has from the previous sections. It is especially important -to counterbalance the desired terseness of the detailed design; if you feel -your detailed design is rudely short, consider making this section longer -instead. # Drawbacks [drawbacks]: #drawbacks -Why should we *not* do this? # Alternatives [alternatives]: #alternatives -What other designs have been considered? What is the impact of not doing this? # Unresolved questions [unresolved]: #unresolved-questions -What parts of the design are still TBD or unknowns? # Future work [future]: #future-work -What future work, if any, would be implied or impacted by this feature -without being directly part of the work? From 7849464503a648f51beab70812c58966e3050c77 Mon Sep 17 00:00:00 2001 From: Shahrukh Khan Date: Fri, 14 May 2021 22:44:42 -0500 Subject: [PATCH 3/5] Review comments --- rfcs/0003-languages.md | 49 ++++++++++++++++++++---------------------- 1 file changed, 23 insertions(+), 26 deletions(-) diff --git a/rfcs/0003-languages.md b/rfcs/0003-languages.md index 37ef82a..abf85aa 100644 --- a/rfcs/0003-languages.md +++ b/rfcs/0003-languages.md @@ -1,21 +1,21 @@ --- -feature: (languages) -start-date: (2021-04-30) -author: (Shahrukh Khan) -related-issues: (None) +feature: tools-and-programming-languages +start-date: 2021-04-30 +author: Shahrukh Khan +related-issues: None --- # Summary [summary]: #summary -This RFC describes how language support is to be implemented in Soxin. This -breaks down in two areas: +This RFC describes how tools and programming languages support is to be +implemented in Soxin. This breaks down in two areas: * How languages are defined, i-e how to define the language and its properties i-e its compiler, tools, editor plugins etc. How the user can define the - defualt plugins for a language in his editor(s). + default plugins for a language in their editor(s). * How the user can select default set of languages and its required tools in - his editor, and how to override default settings on the editor. + their editor, and how to override default settings per-editor. # Motivation [motivation]: #motivation @@ -50,7 +50,7 @@ soxin.programming.tools = { tmux = { /* ... */ }; } ``` -This allows soxin to define its own support for languages and tools, while +This allows Soxin to define its own support for languages and tools, while allowing room for user customization as well. Similar to RFC 2, each programming language must include a key for each editor @@ -67,17 +67,18 @@ Similar to RFC 2, a `soxin.settings.programming.languages` and to choose his programming stack. The only permitted values here shall be the defined in `config.soxin.programming.`. This option shall be of type `Array` of `str`, with apply function which iterate over the array and find -appropriate language or tool. +appropriate languages or tools. -### Per-editor +### Per-program -Each editor that supports a language must provide a -`soxin.programs..language` and `soxin.programs..tool` -option to allow the user to override the programming stack settings per editor. -These options will default to `config.soxin.settings.programming.`, -and thus will be of type `attrs`. Similar to RFC 2, they will also have will -also allow `str` and have an `apply` function that will lookup the theme -from `config.soxin.programming.` for each option. +Each program that supports a language must provide a +`soxin.programs..programming.language` and +`soxin.programs..programming.tool` option to allow the user to +override the programming language stack settings per program. These options will default +to `config.soxin.settings.programming.`, and thus will be of type +`attrs`. Similar to RFC 2, they will also have will also allow `str` and have +an `apply` function that will lookup the theme from `config.soxin.programming.` +for each option. # Examples and Interactions [examples-and-interactions]: #examples-and-interactions @@ -137,13 +138,13 @@ let The options of the `programs.neovim` have been modified for simplicity's sake. -# Examples and Interactions -[examples-and-interactions]: #examples-and-interactions - - # Drawbacks [drawbacks]: #drawbacks +Adds additional layer of segregation between `soxin.programs` and +`soxin.programming.tools`. Which will require Soxin developers to be cognizant +about where to add a new language or a tool, thus adding additional layer of +complexity. # Alternatives [alternatives]: #alternatives @@ -153,7 +154,3 @@ The options of the `programs.neovim` have been modified for simplicity's sake. [unresolved]: #unresolved-questions -# Future work -[future]: #future-work - - From 8828615b9b434343c2aa71f072d893c3c4419f4e Mon Sep 17 00:00:00 2001 From: Shahrukh Khan Date: Sat, 31 Jul 2021 00:53:13 -0500 Subject: [PATCH 4/5] Update RFC --- rfcs/0003-languages.md | 106 +++++++++++++++++++++++++++-------------- 1 file changed, 71 insertions(+), 35 deletions(-) diff --git a/rfcs/0003-languages.md b/rfcs/0003-languages.md index abf85aa..059d725 100644 --- a/rfcs/0003-languages.md +++ b/rfcs/0003-languages.md @@ -29,11 +29,11 @@ feature integrates with the project was needed. ## Language definition -Languages would be defined in a module named `soxin.programming.languages`. +Languages would be defined in a module named `soxin.programmingLanguagesModules`. Each language, would be an attribute set in this module: ``` -soxin.programming.languages = { +soxin.programmingLanguagesModules = { go = { /* ... */ }; java = { /* ... */ }; python = { /* ... */ }; @@ -41,11 +41,11 @@ soxin.programming.languages = { ``` ## Tools defination -Programming tools will be defined in a module named `soxin.programming.tools`. +Programming tools will be defined in a module named `soxin.toolsModules`. Each tool will be an attribute set in this module. ``` -soxin.programming.tools = { +soxin.toolsModules = { git = { /* ... */ }; tmux = { /* ... */ }; } @@ -62,22 +62,22 @@ to configure that plugin. ### Globally -Similar to RFC 2, a `soxin.settings.programming.languages` and -`soxin.settings.programming.tools` option would be introduced to allow the user +Similar to RFC 2, a `soxin.settings.programmingLanguages` and +`soxin.settings.tools` option would be introduced to allow the user to choose his programming stack. The only permitted values here shall be the -defined in `config.soxin.programming.`. This option shall be of type +defined in `config.soxin.`. This option shall be of type `Array` of `str`, with apply function which iterate over the array and find appropriate languages or tools. ### Per-program Each program that supports a language must provide a -`soxin.programs..programming.language` and -`soxin.programs..programming.tool` option to allow the user to -override the programming language stack settings per program. These options will default -to `config.soxin.settings.programming.`, and thus will be of type +`soxin.programs..programmingLanguages` and +`soxin.programs..tools` option to allow the user to +override the programming language stack and tools settings per program. These options will default +to `config.soxin.settings.`, and thus will be of type `listOf` `attrs`. Similar to RFC 2, they will also have will also allow `str` and have -an `apply` function that will lookup the theme from `config.soxin.programming.` +an `apply` function that will lookup the programmingLanguage/tools config from `config.soxin.` for each option. # Examples and Interactions @@ -87,51 +87,87 @@ Here's how one could define a language and a tool implementing only the `neovim` editor: ``` -{ pkgs, ... }: +# ProgrammingLanguages +{ mode, config, pkgs, lib, soxin, ... }: + +with lib; { - config.soxin.programming.languages = { - go = { + config.soxin.programmingLanguagesModules.go = (mkMerge [ + { neovim = { plugins = [ pkgs.neovim.go ]; extraRC = '' ''; }; - }; + } - config.soxin.programming.tools = { - git = { + /*(optionalAttrs (mode == "home-manager") { + programs.go = { + enable = true; + }; + })*/ + ]); +} + +#tools +{ mode, config, pkgs, lib, soxin, ... }: + +with lib; +{ + config.soxin.toolsModules.git = (mkMerge [ + { + neovim = { plugins = [ pkgs.neovim.fugitive ]; extraRc = '' ''; }; - }; - }; + } + + /*(optionalAttrs (mode == "home-manager") { + programs.go = { + enable = true; + }; + })*/ + ]); } ``` Here's how this would be implemented on the editor side: ``` -{ config, lib, ... }: +{ mode, config, pkgs, lib, soxin, ... }: +with lib; let cfg = config.soxin.programs.neovim; - goSupportRc = cfg.programming.languages.go ? ""; - gitSupportRc = cfg.programming.tools.git ? ""; - goSupportPlugins = cfg.programming.languages.go.plugins ? []; - gitSupportPlugins = cfg.programming.tools.git.plugins ? []; +in { - config.program.neovim = lib.mkIf soxin.programs.neovim.enable { - enable = true; - configure = '' - /* Some configuration */ - ${goSupportRc} - ${gitSupportRc} - ''; - - plugins = [ /* Some plugins */ ] ++ goSupportPlugins ++ gitSupportPlugins; + options = { + soxin.programs.neovim = soxin.lib.mkSoxinModule { + inherit config; + name = "neovim"; + includeProgrammingLanguages = true; + includeTools = true; + }; }; + + config = mkIf cfg.enable (mkMerge [ + (optionalAttrs (mode == "home-manager") { + programs.neovim = mkMerge [ + { inherit (cfg) enable; } + + { + plugins = flatten (map + (v: + v.extensions + ) + cfg.programmingLanguages ++ cfg.tools); + } + + ]; + }) + ]); } ``` @@ -142,7 +178,7 @@ The options of the `programs.neovim` have been modified for simplicity's sake. [drawbacks]: #drawbacks Adds additional layer of segregation between `soxin.programs` and -`soxin.programming.tools`. Which will require Soxin developers to be cognizant +`soxin.tools`. Which will require Soxin developers to be cognizant about where to add a new language or a tool, thus adding additional layer of complexity. From b51b33212ddf9ae2159234002dde40d95918893b Mon Sep 17 00:00:00 2001 From: Shahrukh Khan Date: Sat, 23 Oct 2021 10:58:30 -0500 Subject: [PATCH 5/5] Update rfcs/0003-languages.md Co-authored-by: Wael Nasreddine --- rfcs/0003-languages.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0003-languages.md b/rfcs/0003-languages.md index 059d725..8aa357c 100644 --- a/rfcs/0003-languages.md +++ b/rfcs/0003-languages.md @@ -64,7 +64,7 @@ to configure that plugin. Similar to RFC 2, a `soxin.settings.programmingLanguages` and `soxin.settings.tools` option would be introduced to allow the user -to choose his programming stack. The only permitted values here shall be the +to choose their programming stack. The only permitted values here shall be the defined in `config.soxin.`. This option shall be of type `Array` of `str`, with apply function which iterate over the array and find appropriate languages or tools.