Re: Racket packages / build system

[Christopher Lemmer Webber <cwebber@dustycloud.org>]

Bonface M. K. writes:

> Christopher Lemmer Webber <cwebber@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.