"resource:" path resolution sucks

[jckarter]

You can't save an image to another directory without breaking everything. Could "resource:" be made smarter or less fragile?

[jckarter]

According to yac_srck on IRC there is also stuff that breaks when you refer to an image by an absolute path vs. a relative path in the -i option. We should investigate whether there are bugs in the resource: directory setup.

[timor]

There is another thing which is a bit impractical with the current situation: Factor assumes a system-wide installation in a writable location.

This is problematic compared to typical per-site/per-user conventions in programming language library search under linux. In our specific case, we are using NixOS systems. This has a number of consequences (some of which I hack around in a rather "creative" way 1,2 right now...)

The most visible one is that the "work" resource points to a read-only, system-wide location (I would prefer a per-user default here). Thus, words like scaffold-work don't work out-of-the-box in such an environment.

Additionally it would be nice if it were possible to specify an absolute path to an image whenever factor looks for one in pre-defined locations. This way, we could generate, store, and distribute images in a NixOS-friendly way and even be able to use nix's specific properties to "version-control" our factor images for deployment.

Ideally, there would separate concepts for the following things, which are not independent at the moment:

• path to factor-installation (read-only)
• path to resources, where it might make sense to add an additional "dispatch" layer on the first element after "resource:...", that can be per-user, or fall back to a default
  • this would include the "work" resource, which happens to be a vocab root, too...
• path to factor images for the purpose of bootstrapping and deployment

[timor]

I just discovered these related issues: #936, #495