nix-community/dream2nix
1
1
Fork 0
mirror of https://github.com/nix-community/dream2nix.git synced 2024-08-16 18:00:30 +03:00
Code Issues Projects Releases Wiki Activity

docs: minor readme improvements

Browse Source
This commit is contained in:
DavHau 2021-09-29 22:29:09 +01:00
parent ed145173f5
commit 443f4a983b
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
README.md
View File

@ -19,9 +19,9 @@ It focuses on the following aspects:
2nix converters, or in other words, tools converting instructions of other build systems to nix build instructions, are an important part of the nix/nixos ecosystem. These converters make packaging workflows easier and often allow to manage complexity that would be hard or impossible to manage without.
Yet the current landscape of 2nix converters has certain weaknesses. Existing 2nix converters are very monolithic. Authors of these converters are often motivated by some specific use case and therefore the individual approaches are strongly biased and not flexible. All existing converters have quite different user interfaces, use different strategies of parsing, resolving, fetching, building while providing significantly different options for customizability. As a user of such converter it often feels like there is some part of it that suits the needs well, but at the same time it has undesirable hard coded behaviour. Often one would like to use some aspect of one converter combined with some aspect of another converter. One converter might do a good job in reading a specific lock file format, but lacks customizability for building. Another converters might come with a good customization interface, but is unable to parse the lock file format. Some converters are restricted to use IFD or FOD, while others enforce code generation.
Yet the current landscape of 2nix converters has certain weaknesses. Existing 2nix converters are very monolithic. Authors of these converters are often motivated by some specific use case and therefore the individual approaches are strongly biased and not flexible. All existing converters have quite different user interfaces, use different strategies of parsing, resolving, fetching and building while providing significantly different options for customizability. As a user of such converter it often feels like there is some part of it that suits the needs well, but at the same time it has undesirable hard coded behaviour. Often one would like to use some aspect of one converter combined with some aspect of another converter. One converter might do a good job in parsing a specific lock file format, but lacks customizability for building, while another one provides a good customization interface, but is unable to parse the lock file format. Some converters are restricted to use IFD or FOD, while others enforce code generation.
The idea of this project is therefore to create a standardized, generic, modular framework for 2nix solutions, aiming for better flexibility, maintainability and usability.
The idea of this project is to create a standardized, generic, modular framework for 2nix solutions, aiming for better flexibility, maintainability and usability.
The intention is to integrate many existing 2nix converters into this framework, thereby improving many of the previously named aspects and providing a unified UI for all 2nix solutions.