Chris Marusich <cmmarus...@gmail.com> writes: > Of course, if there is a way to solve this class of problem more > generally without introducing impurities, that'd be great. I just can't > think of one at this time.
There is existing code in Guix that puts things into the store which depend on things outside of the store. The specific examples I know of are: - When Guix downloads source files from the Internet and puts them into the store. - When Guix finds Guile modules in the GUILE_LOAD_PATH and puts them in the store, as a result of using 'with-imported-modules' with a G-Expression. - Other code that exists explicitly to add files to the store, such as the 'local-file' procedure. In these cases, what winds up in the store ultimately comes from the outside world. I'm not 100% sure, but I think that when something from "outside" is put into the store in this way, it's done outside the scope of a derivation, since derivations should only be able to access files that exist in the store. Anyway, this means that technically, we probably could come up with a solution that takes the current value of an environment variable and ultimately incorporates it into a build that creates the new profile generation. However, it doesn't change the fact that this class of problem will probably continue to occur on foreign distributions, so I still think it might be best to deal with the problems on a case by case basis. -- Chris
signature.asc
Description: PGP signature
