Hello! Tomas Volf <[email protected]> skribis:
> after a pull, seeing the news, and subsequent rollback I went on > exploring how the new feature of the record system works. It seems to > work just for some fields (e.g., I can use it with inputs, but not with > version), which is quite confusing. Additionally, it does not seem to > allow cross-references (e.g., I cannot use inputs in propagated-inputs). It works for thunked fields only, just like self references such as ‘this-package’. (For reference, this was discussed at <https://codeberg.org/guix/guix/pulls/6955>.) > However the reason I am writing this email is this part from the news: > >> the newly introduced bindings could shadow same-named bindings > > which sounds quite annoying to deal with. Does this basically mean that > adding new field to any record in Guix can break arbitrary user code? The only risk is if you were doing: (define (foo inputs) (package (inherit xyz) ;; … (inputs (do-something inputs)))) Previously the ‘inputs’ in the ‘inputs’ field body would refer to the outer ‘inputs’; now it refers to the inherited field value. It’s a very narrow case. In the entire code base, I found two occurrences of this. > For now, I will spend the weekend checking that all my code does not > have any naming conflict, but I am not sure what to do next. Especially > given the fact that there is no warning when the shadowing occurs. > > I assume committers will ensure that no record will have fields that are > named the same way as any built-in procedure (and possibly some > hand-picked SRFIs and ICE-9s?), but in what matter shall I write my own > code? Is there some reserved prefix, I can be sure no record will ever > used for its fields? How should I future-proof my code? You’re raising good points. I think name clashes today are unlikely (in Guix itself we’d discover them not with warnings but with tests and CI for packages). Also, shadowing builtins is not a completely new thing. When you do: (package ;; … (version "1.2.3") (source (… (string-append … version ".tar.gz")))) … the ‘version’ in the body of ‘source’ is the one just above, not Guile’s builtin ‘version’ procedure. The extra shadowing (only when inheriting, only in thunked fields) doesn’t fundamentally change this. Could you try your config/channels/code with this new feature and see if you stumble upon any issue? Thanks for your feedback! Ludo’.
