[bug#74078] [PATCH] gnu: Add dart

["Jørgen Kvalsvik" <j@lambda.is>]

On 11/5/24 06:20, Maxim Cournoyer wrote:
> Hi Jørgen,
> 
> Jørgen Kvalsvik <j@lambda.is> writes:
> 
>> * gnu/packages/dart.scm: New file.
>> * gnu/local.mk: Register it.
>>
>> Change-Id: Idbdcf4e30790b3225bf86a36a0a4c4b081b557aa
>> ---
>>   gnu/local.mk          |   1 +
>>   gnu/packages/dart.scm | 101 ++++++++++++++++++++++++++++++++++++++++++
>>   2 files changed, 102 insertions(+)
>>   create mode 100644 gnu/packages/dart.scm
>>
>> ---
>>
>> Hello,
>>
>> This is a port of the nixpkgs Dart compiler package [1]. I am interested
>> in it specifically because it is a transitive dependency of Hugo [2],
>> and I figured I other people might be interested in these packages, too.
>>
>> The from-source build of Dart is quite the pain (nixpkgs seems to have
>> given up, but I do not know the story there). I looked around and while
>> I did not find a strict rule saying "source only", it does stand out by
>> relying on prebuilt artifacts. For my current needs it is good enough,
>> and I hope that in the future it could get a proper source build. I saw
>> there was an effort a few years ago, but it appears to have stopped
>> completely.
> 
> What kind of prebuilt artifacts are we talking about?
> 
> [...]
> 
>> +(define-public dart-3.5
>> +  (package
>> +    (name "dart")
>> +    (version "3.5.4")
>> +    (source (origin
>> +              (method url-fetch)
>> +              (uri (string-append
>> +                    "https://storage.googleapis.com/dart-archive/channels/stable/release/"
>> +                    version "/sdk/dartsdk-"
>> +                    (match (%current-system)
>> +                      ("x86_64-linux" "linux-x64")
>> +                      ("i686-linux" "linux-ia32")
>> +                      ("aarch64-linux" "linux-arm64")
>> +                      (_ "unsupported"))
>> +                    "-release.zip"))
>> +              (sha256
>> +               (base32 (match (%current-system)
>> +                  ("x86_64-linux" "0rv9rp8g5blhncqwciymhxh3z2832yp54lphxgsvkmm9y8s5w34d")
>> +                  ("i686-linux" "02kv119swcp7y4n3yb2i5a4dagjpf0zq3b3an1apahj5zn6ak41g")
>> +                  ("aarch64-linux" "1v437zpksk0jhib6vhpcbvv715mv32zmwby8b3p9qd3k67fn87d9")
>> +                  (_ "0000000000000000000000000000000000000000000000000000"))))))
> 
> Given the "sources" are architecture-specific...
> 
>> +    (build-system copy-build-system)
> 
> ... and that we aren't building them, I suppose we are talking about
> binary executables.

Correct.

> [...]
> 
> While we do have some other packages that do not bootstrap entirely such
> as Vala, the situation is not comparable with simply fetching its
> binaries and copying them to the store.
> 
> I don't think this can be added to GNU Guix as it is, as our policies
> are strict about being able to build from source (see the pain we go
> through to build recent rust for example -- a long bootstrap chain
> rooted in mrustc).
> 
> I'd suggest creating a merge request against a different channel that do
> not have such high standards/requirements such as NonGuix [0].
> 
> I'm now closing this ticket.  Thank you for producing it, and apologies
> for the outcome, but I think it's important to stick to this important
> property of Guix called 'referential transparency', which wouldn't be
> quite the same if the references were opaque binaries :-).

No problem - frankly, I expected as much (and appreciate it), but wanted 
to check to be sure. As Sharlatan pointed out there is an older, maybe 
stale, bootstrapping effort, which could be revived.

As for Hugo (which is what I cared about) it has a bunch of other 
dependencies that aren't in guix and that don't really mesh too well 
since the go build system doesn't do modules yet, and some dependencies 
are .zip/modules-only.

> 
> [0]  https://gitlab.com/nonguix/nonguix/
>