| ... | @@ -2,7 +2,7 @@ | ... | @@ -2,7 +2,7 @@ |
| 2 | Zigmod is a prototype package manager for Zig. An official one will eventually be made so I wanted to add this page to the docs to go over some of the guiding principles used in this project. Some are general good practice for app development but there will be added context in how they apply to making a package manager. | 2 | Zigmod is a prototype package manager for Zig. An official one will eventually be made so I wanted to add this page to the docs to go over some of the guiding principles used in this project. Some are general good practice for app development but there will be added context in how they apply to making a package manager. |
| 3 | | 3 | |
| 4 | ### 1. Be declarative | 4 | ### 1. Be declarative |
| 5 | `zig.mod` is a static Yaml file that does not contain any Zig code. This was intentional to not allow packages to run arbitrary code on the developer's machine. A maintainer's computer is an arguably much more high risk attack surface so the trust of code should be kept to a minimum. Given that the environment may contain API/ssh/etc keys that provide access to things far wider than just the user's computer. | 5 | `zig.mod` is a static Yaml file that does not contain any Zig code. Placing packages' definition in its own file (say as opposed to in `build.zig`) was an intentional decision from the start to not allow packages to run arbitrary code on the developer's machine. A maintainer's computer is an arguably much more high risk attack surface so the trust of code should be kept to a minimum. Given that the environment may contain API/ssh/etc keys that provide access to things far wider than just the user's computer. |
| 6 | | 6 | |
| 7 | ### 2. Be Immutable/Avoid the network as much as possible | 7 | ### 2. Be Immutable/Avoid the network as much as possible |
| 8 | The network is slow and unreliable. So we should cache only what we need and avoid fetching unchanged data. This is achieved from a user's perspective by using versions on your dependencies that dont change. For example tags or commits when using git, or specifying a hash when using http. | 8 | The network is slow and unreliable. So we should cache only what we need and avoid fetching unchanged data. This is achieved from a user's perspective by using versions on your dependencies that dont change. For example tags or commits when using git, or specifying a hash when using http. |
Meghan Denny <hello@nektro.net> 2021-02-23 14:32:36 -08:00