NixOS compatibility

[timor]

There are several problems right now with Factor under NixOS. This issue is intended to keep track of the details.

NixOS has some properties which prevent Factor working as intended out-of-the-box:

• Non-FHS filesystem, no /usr/lib, /bin/ls, /usr/share/ etc. This means that all references to absolute paths like /usr/share/timezone must be patched during build phase.
• Strict sandbox build environment
• All installed software and build time prerequisites reside in a read-only store
• "Clone our current stable/master branch and develop your software" does not work well and is discouraged. Development environments are assumed to be stable and reproducible.

The following issues need to be addressed to get it working without any major hack-arounds:

• [ ] Trying to use ldconfig when loading libraries fails. (#2171)
• [ ] work resource path can not be in the same location as factor installation (#364, #936, workaround)
• [ ] Non-deterministic binaries (#2114). For building Factor or deploying an Application once, this is not a problem. However, packages included upstream are usually built twice to ensure deterministic build products.
• [ ] Staging images can not be cached when using Factor deployment for building Nix packages, because all build inputs must be deterministic. This is an inherent limitation unless a stable set of images is distributed with/can be compiled from a given Factor version at installation time.
• [ ] Cannot find image from -i=image-name only during deployment (#2188)
• [ ] Mapping from Factor git revisions to known-good bootstrap images. This would allow to create an update script for the derivation. (#2417)

To run the core tests after building:

• [ ] Some unit tests assume FHS layout (workaround)
• [ ] Some unit tests assume internet connection
• [ ] Some unit tests use local network services. Note that these kinds of tests are possible under NixOS, but run as OS-level tests, with dedicated VM setup.

If the development version is intended to be distributed:

• [ ] ~Official release is quite dated (#2177)~ There is no development version release. NixOS upstream prefers tagged releases with increasing version numbers. E.g. to package the development version, it would be useful to have "0.99-pre1,0.99-pre2,..." releases which can be referenced when fetching the sources (even if they don't have any semantic meaning)

To allow using save and friends during development

• [ ] Split image-path semantics somehow to be able to load (per default?) from a read-only path, but have different location that save. Ideally, this would extend to the whole "resource-path" logic somehow. My current setup: Start factor from read-only store, then to develop, set "resource-path" and image-path to my local factor git repo, run refresh-all. UPDATE: This works as intended with the provided shell.nix if Factor is not installed from the store but with a local git checkout.

[mrjbq7]

Great list of stuff to fix! I need to get a NixOS installation I can test with, or have the intersection between Factor users and NixOS users contribute some patches.

By the way, I'm not sure what you mean by "official release is quite dated". Our last release of version 0.98 was July 2018 and 320 commits ago? Is that "quite dated"?

[timor]

You are right, "quite dated" is a subjective term. I was mainly having the development branch in mind.

[timor]

While I do have some patches/commits that deal with some issues, these are quite NixOS specific, and could be too radical for general linux usage of Factor.

I think it is important to find the correct balance. I think a certain amount of build-time patching is acceptable if otherwise the Factor source would have to be special-cased in very inconvenient ways.

[mrjbq7]

Perhaps we should add a nixos operating system type like Linux. Make it a subclass of Linux and then let’s see where the nixos exceptions are?

On Sep 9, 2019, at 3:18 PM, timor [email protected] wrote:

While I do have some patches/commits that deal with some issues, these are quite NixOS specific, and could be too radical for general linux usage of Factor.

I think it is important to find the correct balance. I think a certain amount of build-time patching is acceptable if otherwise the Factor source would have to be special-cased in very inconvenient ways.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[erg]

All of the patches have to get in somehow or else the branch will bitrot. You can define a new platform that inherits from unix or even linux.

! existing code, you'll have to tweak it
IN: system
SINGLETONS: windows macosx linux freebsd ;

UNION: bsd freebsd ;
UNION: unix macosx linux freebsd bsd ;

[timor]

cc @spacefrogg

[timor]

Updated Issue description regarding image paths.

[timor]

I had a discussion about this with @spacefrogg, and we came to the following conclusions:

1. Provide a NixOS platform like @erg suggested above, adjust all relevant places in the factor tree

2. From the Nix perspective, we identified the following use cases:

   1. The tree-wide default derivation, which, when installed, can be run interactively, and will also be the default dependency for any derivation that depends on factor at build time
   2. Developing Factor applications without having to change the factor sources or run a custom image
   3. Working on the Factor sources themselves, possibly having to bootstrap from custom images

2.i Is what is implemented at the moment using patches, and should be covered by doing 1. and providing the NixOS platform specifics in the official Factor sources.

2.ii Only works at the moment by working around #364, since "resource:work" is in a read-only location when installed via Nix. This can be addressed by fixing #364 proper (#936 was an approach), or maybe special-casing scaffolding and vocabulary roots to use some other default, e.g. ~/.local/share/factor on NixOS ("resource:local" ?).

2.iii ~is the trickiest, because Factor's build script can not be used on NixOS systems as it is.~ Also, and this is not a Factor-specific problem, setting up development environments for compilers/interpreters with custom sources is not straight-forward under NixOS. I can imagine two solutions for this last use case: a.) Provide nix support in the official factor sources, so that a freshly cloned Factor source tree provides all Nix-specific helpers. b.) Take the current custom builder, and provide it, together with e.g. some direnv convenience, as a kind of development environment manager, as a kind of "Factor-development" package in NixOS.

@vrthra: You contributed the original factor-lang derivation, correct? Do you have thoughts about this from the maintainer's point of view?

[timor]

Updated above comment to reflect latest changes.

Regarding 2.iii, the shell.nix allows to use the Factor-provided build script as-is. The code which makes use of that from the NixOS side is not upstreamed yet. It will probably only make sense once there is a new release (dev or stable, but at least tagged). Also without something like #2417 switching to a new version involves quite a bit of manual work.

[ja-cop]

Just wanted to note that most of this is also relevant for packaging Factor on other Linux distributions, but Guix notably also uses a non-FHS filesystem. I have a WIP package for Guix here.

For Factor to be included in the upstream Guix package repository, it would also need to be bootstrapped from source, which is another challenge entirely, but probably a healthy undertaking for Factor in general; this post on the Guix blog describes a similar problem in the C# ecosystem.

[spacefrogg]

As a quite comprehensive effort of packaging Factor for NixOS just landed in nixpkgs. I would like to point to the relevant build script, as it provides an accurate overview of the measures that have to be taken to make Factor fit for the platform.

EDIT: See also the Factor documentation in nixpkgs about how I approached scaffolding on a system-wide installation.

[mrjbq7]

I’d love to make this better for 0.101.

[timor]

I’d love to make this better for 0.101.

@spacefrogg with regards to that, could you take a look at the issue description if it is still accurate/useful?

[spacefrogg]

I am not empowered to change the initial description. So, I will comment on it below (I mean, who doesn't like some nice TOFU?):

There are several problems right now with Factor under NixOS. This issue is intended to keep track of the details.

NixOS has some properties which prevent Factor working as intended out-of-the-box:

• Non-FHS filesystem, no /usr/lib, /bin/ls, /usr/share/ etc. This means that all references to absolute paths like /usr/share/timezone must be patched during build phase.

• Strict sandbox build environment

• All installed software and build time prerequisites reside in a read-only store

• "Clone our current stable/master branch and develop your software" does not work well and is discouraged. Development environments are assumed to be stable and reproducible.

Still accurate, I believe.

The following issues need to be addressed to get it working without any major hack-arounds:

• [ ] Trying to use ldconfig when loading libraries fails. (build fails with musl libc systems #2171)[ ] work resource path can not be in the same location as factor installation ("resource:" path resolution sucks #364, Local resource paths #936, workaround)[ ] Non-deterministic binaries (How to get bit-identical factor.images from the same boot image? #2114). For building Factor or deploying an Application once, this is not a problem. However, packages included upstream are usually built twice to ensure deterministic build products.[ ] Staging images can not be cached when using Factor deployment for building Nix packages, because all build inputs must be deterministic. This is an inherent limitation unless a stable set of images is distributed with/can be compiled from a given Factor version at installation time.[ ] Cannot find image from -i=image-name only during deployment (Lookup of factor image during application deployment #2188)[ ] Mapping from Factor git revisions to known-good bootstrap images. This would allow to create an update script for the derivation. (Keep a database of known-working bootstrap images for Factor builds #2417)

I am quite satisfied with our current approach here and in the accompanying patch, which could be made part of the new factor platform. What it does, is that it let's factor read its ld.so.cache from an environment variable. The correct ld.so.cache is fed to factor via a shell wrapper setting the variable. This proved to be a nice composable and extensible interface.

To run the core tests after building:

• [ ] Some unit tests assume FHS layout (workaround)

Still accurate. This should be solvable by the new platform.

• [ ] Some unit tests assume internet connection
• [ ] Some unit tests use local network services. Note that these kinds of tests are possible under NixOS, but run as OS-level tests, with dedicated VM setup.

This has been taken care of in the builder. I don't see a great need for extra support. If willing, denoting a test set with only tests without network connections/services or GUI (should be added) could improve test coverage.

If the development version is intended to be distributed:

• [ ] ~Official release is quite dated (Release schedule/plan? #2177)~ There is no development version release. NixOS upstream prefers tagged releases with increasing version numbers. E.g. to package the development version, it would be useful to have "0.99-pre1,0.99-pre2,..." releases which can be referenced when fetching the sources (even if they don't have any semantic meaning)

I believe this is taken care of. The new packaging should make it fairly easy to use a development version of the compiler. I don't see any need for extra support from Factor.

To allow using save and friends during development

• [ ] Split image-path semantics somehow to be able to load (per default?) from a read-only path, but have different location that save. Ideally, this would extend to the whole "resource-path" logic somehow. My current setup: Start factor from read-only store, then to develop, set "resource-path" and image-path to my local factor git repo, run refresh-all. UPDATE: This works as intended with the provided shell.nix if Factor is not installed from the store but with a local git checkout.

Yeah, this is a generally contentious point. Due to it's highly dynamic and malleable nature, one would be tempted to modify parts of the 'core' also, having immediate write access likely lowers opportunity cost for contributions. Still, it may be worth the effort to enable this split for wider adoption from distributions. So if Factor would not force read/write locations but would happily accept them, would be ideal.

[timor]

Thanks! If you want, feel free to open a new issue and then we'll close this here in favor of that. Otherwise I'll try to change the description here.

[spacefrogg]

I would like to keep this issue. It has some good reasoning laid out already, which I wouldn't like to hide by creating a separate one.