Bonface M. K. writes: > Christopher Lemmer Webber <cweb...@dustycloud.org> > writes: > >> Dimos Dimakakos writes: >> >>> Bonface M. K. writes: >>> >>>> To simply put it, AFAIU updating a package would >>>> require racket to update it's references(either >>>> links, and other references that I won't go into), >>>> hence creating some form of "global state"; >>>> thereby if you use raco, every package updated >>>> would lead to some update with racket's search >>>> paths or dirs somewhere. Any ideas to overcome >>>> this wall? (or anything I've got wrong somewhere?) >>> >>> This was one of the main problems that I also encountered when working >>> on this. racket2nix solves this by generating a temporary environment >>> (by coping most of the racket folders and the deps needed as writable >>> folders) where it installs with raco and then tries to update the global >>> state of racket. >>> >>> To be honest this solution is kinda hacky and also slow, but I couldn't >>> think of another one at the time I tried to work on the issue. It's a >>> reality that the racket install system is quite stateful and also many >>> operations seem to try to touch files. Installing with raco for example >>> will try to recompile the dependencies of the new package and other such >>> examples. >>> >>> Anyway, I hope you can find a way to move this forward! >> >> I wonder if it would be a good idea to copy many of the points from this >> email and the parent to racket-users or racket-dev and see if someone >> more familiar with the structure of the system can provide guidance from >> there? >> > > This is a good idea IMHO. I'll go ahead and do > this. Perhaps there's something more important > we've missed or aren't seeing. > >> If we have to go the racket2nix route, it would be better than nothing I >> guess. >> > > Yeah. I'm considering going though this route as a > last resort. I don't understand the nix DSL > syntax(though it reads alot like Haskell!). > >> Another possible route: don't use the Racket installer tooling. >> Instead, read the info.rkt file of the package to understand what raco >> *probably would* do, and then do it in a more Guix way instead. >> >> What do you think of that route? > > I've considered doing this... studying raco's source and seeing how it > actually does and sets up things. I'd rather do this than the above, > but it would take more time and would lead to alot more boiler plate I > think... I'm not entirely sure about how to work around the global > state though...
Regarding the boilerplate, not sure it needs to from a package-definitions perspective... if the info.rkt can be read in the general case, this could be the racket-build-system that does most of the work (probably even by reading the very same info.rkt) rather than it being output'ed from an importer definition. > First, let's consult with the racket-devel and racket-user ML and see > what those communities have to suggest... Yes, good idea.
