The following sections describe the agenda of the meeting and also serve as a place to put the corresponding meeting notes. After the meeting, these notes are moved to https://github.com/nixpkgs-architecture/meetings. This HedgeDoc link will be reused for all subsequent meetings.
- Recording link: https://www.youtube.com/watch?v=8OUUQcpDCfQ
- Who records: @infinisil
- Who takes meeting notes: @infinisil
- Who leads the meeting: @infinisil
- Member updates
- Uploaded to YouTube now
- Format of these meetings
- @infinisil: Standup meetings?
- @qyliss: Joined all the meetings, but not applied to the team. Wouldn't join standup meetings because not much time during the week
- @infinisil: Start out with standup, lead into technical discussions
- @qyliss: Should be fine, as long as standup doesn't take too long
- @infinisil:
- Looked at Guix and Lua, homoiconicity
- Started writing a document for what the problem with bash is
- @j-k: homoiconicity discussion -> other languages? Somebody tried it with Lua but only a blog post https://dercuano.github.io/notes/flat-dict-lang.html
- @tomberek: Read about execline, needs a lot of helpers, tradeoff with eval time (would like to see a PoC)
-
@infinisil: Motivations for replacing bash?
-
@Mindavi: Cross compiling to Windows is a hassle, hard to do with default bash code, but not very important since it's not supported anyways
-
@tomberek: Bash is often used to do simple things, but it brings in system-specific dependencies we don't necessarily need, creating a file, etc.
- @infinisil: WASM goes into that
-
@infinisil: Does bash matter when most people don't have to write bash for packaging?
- @qyliss: Doesn't matter that much, not a lot of bash code and doesn't need to be changed a lot. OSH might be good for that because of that
-
@Gytis: Anything that supports a proper structure and builtins/libraries (coreutils-like) is good. More readable syntax would be great
- Eelco's thesis has some points for bash https://edolstra.github.io/pubs/phd-thesis.pdf
-
@tomberek: How do other big ecosystems package stuff? Most will be bash functions, should we have similarity for easily being able to port stuff?
- @Gytis: Should be fine if the language is somewhat easily convertible
-
@qyliss: Strengthens arguments for OSH: bash-like shell, people are used to it, no trouble switching to it. OSH might provide better arrays and co.
- @infinisil: Should look into if OSH supports libraries/modules
- @qyliss: Try to talk with them to add library support
- @Gytis: Not a big fan of OSH, not a lot of tooling, kind of unstable, for now
- @Gytis: Perfect shell would be https://github.com/nushell/nushell, but it uses rust
- @Gytis: Perfect language would be typescript, but no easily bootstrappable runtime
- @infinisil: Should look into if OSH supports libraries/modules
-
@nbathum: Multiple time-scales. Multiple requirements (testing, smooth transition, bootstrapping, typing), have a matrix where these are taken on in different steps
- @infinisil: People would use OSH-specific features, which then makes later steps harder.
- @qyliss: OSH features are very general programming features, would make it easier to switch in the future (@infinisil: +1). We couldn't get consensus to switch to e.g. typescript. The smaller the change, the easier to get through. OSH is easy to switch to and an improvement
- @Gytis: Anything other than bash should be good
- @infinisil: People would use OSH-specific features, which then makes later steps harder.
-
@Gytis: Language requrements: (If anyone else has anything to add - please do!)
- Easily bootstrapable
- @infinisil: Bootstrappable needed?
- @everybody: Yes!
- @infinisil: Bootstrappable needed?
- Support for real data structures (maps/arrays)
- Builtins to deal with data (regex, contains, write file, copy file)
- Options to expand to other platforms (Windows)
- Must be a shell or have solid meta programming support (so we could imitate a shell)
- Easily testable
- @infinisil: Easier to make changes
- @qyliss: Not necessary, can have a test suite with bash
- @nbathum: There's a type checking library for bash too (not that it'd be recommended: https://github.com/Mythra/typeish) Nice to Have features:
- Solid type system
- Popular?
- Easily bootstrapable
-
@ashkitten: Ruby is bootstrappable, has libraries, portable, data structures. But switching to OSH for now would be good, only something else later. Easier to do it in incremental steps instead of everything at once
- @infinisil: Can't do big steps for users multiple times in short succession. But for bash might be fine since most users don't have to use bash
- @qyliss: Since OSH is 99% compatible with bash it won't be a big problem
- @Gytis: Worried about changing builder and forgetting about it for 10 years
- @qyliss: If somebody thinks it's worth doing more we can do that
- @Mindavi: If a language is more easily changeable, more changes will happen
-
@Gytis: https://www.oilshell.org/release/latest/doc/oil-language-tour.html
-
@j-k: Data structures are sometimes needed
- @qyliss: @stdenv is implemented with call-backs, not implementable with just data structures. E.g. hooks. Leading candidates for a better implementation with better language. Worst parts don't bode well with subprocesses, can't just use another language for the hard parts
-
@ashkitten: If there's not a big switch burden there's not much reason not to switch. Research is worthwhile, see what breaks, check RFC
- @Gytis: Stdenv is OSH compatible now, some changes to make it compatible were merged
- @ashkitten: Then we could switch to OSH by default, but use bash for packages that are broken with OSH
- @qyliss: Just temporary inbetween state, there shouldn't be many packages. More waiting for stability of OSH, e.g. wait for C++ rewrite, drop their Python 2 fork
- @ashkitten: Then we could switch to OSH by default, but use bash for packages that are broken with OSH
- @Gytis: Stdenv is OSH compatible now, some changes to make it compatible were merged
-
(@Eelco): https://edolstra.github.io/pubs/phd-thesis.pdf Page 247 "A language for builders" section
-
@nbathum: Moving away from coreutils and other deps why?
- @Gytis: Easier to bootstrap, less evaluation, performance
- @qyliss: Languages build systems would depend on coreutils
- @Gytis: But only for build, not during runtime
- @qyliss: So needed for bootstrapping. Also coreutils is only one package
- @ashkitten: Portability is a strong argument. Coreutils is unixy, not portable with windows.
-
@infinisil: setup-hooks contains a lot of bash, not just stdenv
- @Fridh: Language builders too
-
@Fridh: Would like to see dependency declarations between hooks
- @qyliss: Would be easier with data structures
- @Fridh: structuredAttrs is important for more complex builders
-
@infinisil: Only mkDerivation, no language builders, instead plugins?
- @Gytis: My prototype uses modules
- @qyliss: Current language builders don't compose well, hope we can get away from language-specific builder functions. Two different ways of building: phases or language-specific builders
- @Fridh: Agreed, sometimes language builders use hooks, makes it more composable
-
-
Homework: