Make the global `package` and `package-base` packages immutable

[Paul Cadman]

Background

The Juvix compiler currently ships with two global packages:

package-base - contains versioned basic definitions like Nat, List
package - contains versions of the PackageDescription module used by Package.juvix package descriptions.

The idea is that a user can write a Package.juvix file against a single version of the PackageDescription module and it will continue to work with newer versions of the Juvix compiler.

These modules are written into the global Juvix configuration directory so that they work well with Juvix tooling. For example you can use jump-to-definition on a symbol defined in a Package.juvix file to see its definition and documentation.

Issue

Currently it is possible for users to edit the modules in these packages. This should not be allowed because the point of Package.juvix files is that they can be shared with other users. The modules that Package.juvix uses should be compatible across installations.

Options

1. Avoid writing these packages to the file system in the first place and load them directly from the compiler binary into memory when required.
2. Compare an expected hash of the contents of the packages with their on-disk hash. If they differ throw an error. The error should include the remedy: juvix clean --global which will remove the global packages, they will be restored with the original copies the next time that the compiler is run.
3. Compare an expected hash of the contents of the packages with their on-disk hash. If they differ simply restore them with the original copies from the binary.
4. Remote the writable bit from the file permissions when writing these files to disk.
5. Something else?

Discussion

Option 1. means that the standard tooling for linking documentation and jump-to-definition will not work with builtins or package files.

Option 2. throws an error when there's only one remedy: juvix clean --global. This may be frustrating to users.

Option 3. silently removes changes that users make to files that they jump to using the Juvix tooling. Perhaps we could mitigate this by adding a comment to these files saying "do not edit".

Option 4. users could just add the writable bit and edit the files any way. It would not be clear to the user why the files are not writable. We'd need to add apply the fix from Option 2 or Option 3 anyway.