Re: Relaxing the restrictions for store item names

["Eidvilas Markevičius" <markeviciuseidvilas@gmail.com>]

So I've being trying to tackle this issue by myself somewhat [1], but
very quickly got into a problem where, even when the restrictions
inside the store-api.cc are gotten rid of, this strange error appears
on an encounter of any non-ASCII character that I don't know how to
deal with:


$ guix build -L . test-ąčęėįšųū
Backtrace:
In srfi/srfi-1.scm:
   673:15 19 (append-map _ _ . _)
   586:17 18 (map1 ("x86_64-linux"))
In guix/scripts/build.scm:
   713:21 17 (_ _)
In guix/store.scm:
  1380:11 16 (map/accumulate-builds #<store-connection 256.99
7f00e9f62870> #<procedure 7f00d651dd70 at
guix/scripts/build.scm:714:43 (t-658ec5b154a5af8-181d)> _ #:cutoff _)
   1298:8 15 (call-with-build-handler #<procedure 7f00cd02ed80 at
guix/store.scm:1333:2 (continue store things mode)> _)
In guix/scripts/build.scm:
   672:18 14 (_ _)
In guix/store.scm:
  2168:25 13 (run-with-store #<store-connection 256.99 7f00e9f62870> _
#:guile-for-build _ #:system _ #:target _)
   1996:8 12 (_ _)
In guix/packages.scm:
  1970:11 11 (_ _)
In guix/store.scm:
  2040:38 10 (_ #<store-connection 256.99 7f00cd2de8c0>)
In guix/derivations.scm:
   833:24  9 (derivation #<store-connection 256.99 7f00cd2de8c0>
"test-ąčęėįšųū-0"
"/gnu/store/g8p09w6r78hhkl2rv1747pcp9zbk6fxv-guile-3.0.9/bin/guile"
("--no-auto-compile" "-L" "/gnu/s…" …) …)
   690:10  8 (derivation-hash _)
    677:5  7 (write-derivation _ #<output: string 7f00d5a3b930>)
    630:4  6 (write-string-list _)
In srfi/srfi-1.scm:
    634:9  5 (for-each #<procedure 7f00d66f4bc0 at
guix/derivations.scm:630:4 (item)>
("/gnu/store/14i2qkvlx6gi98akhwwk7bh26s710s35-test-ąčęėįšųū-0-builder"))
In guix/derivations.scm:
    626:4  4 (_
"/gnu/store/14i2qkvlx6gi98akhwwk7bh26s710s35-test-ąčęėįšųū-0-builder")
In unknown file:
           3 (put-string #<output: string 7f00d5a3b930>
"/gnu/store/14i2qkvlx6gi98akhwwk7bh26s710s35-test-ąčęėįšųū-0-builder"
#<undefined> #<undefined>)
In ice-9/boot-9.scm:
  1685:16  2 (raise-exception _ #:continuable? _)
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `encoding-error' with args `("put-char" "conversion to
port encoding failed" 84 #<output: string 7f00d5a3b930> #\ą)'.


If anyone is knowledgeable enough to tell me why this happens and/or
how to fix it, I'd be grateful. Thanks.

Also, sorry for not opening a separate issue on the debbugs for now; I
will, if it turns out that the problem is a bit more than I can chew
on by myself (which, from the looks of, may actually be the case, but
I'm not entirely sure yet... maybe it's an easy fix).

[1] https://gitlab.com/markeviciuseidvilas/guix

On Tue, Aug 22, 2023 at 9:49 AM Eidvilas Markevičius
<markeviciuseidvilas@gmail.com> wrote:
>
> Hello Guix,
>
> Not long ago, somebody has raised an issue regarding an error that
> occurs whenever some unconventional character is used as the name for
> a store item [0]. Tobias Geerinckx-Rice pointed out that this
> restriction was directly inherited from the Nix source code [1] and
> that, as such, it isn't really a bug. Regardless, I believe that the
> imposed limitation may be undesirable in some situations. One that I
> can think of off the top of my head is packaging a piece of software
> with a name that contains non-Latin characters in it (e.g.,
> "Naršytuvas" by Raštija [2]). Of course, there are very few examples
> of such programs in actual practice, but there's a small chance of
> encountering them from time to time, especially if they're oriented
> towards non-English speaking users, and personally, I don't feel like
> resorting to transliteration is a good solution to this. After all,
> it's 2023, why would such a restriction need to be there in the first
> place when most filesystems are able to handle unicode characters just
> fine?
>
> Another scenario where these artificial restrictions could be a
> potential cause of trouble is when we consider a possibility that Guix
> might be used for packaging and distributing not only software, but
> all kinds of non-executable data such as films, books, music,
> databases, historical documents, website archives, etc. [3]. In the
> case of website archives: say I wanted to package the contents of the
> whole raštija.lt website. When choosing the package name for it,
> should I go with "rastija.lt", "rashtija.lt", or "raštija.lt". The
> latter would be a clear winner in my mind, since it is the canonical
> domain name for that particular site. And for all other types of data
> and media packages, using the official/original titles for their names
> would, too, be much more preferable over making use of any kind of
> transcription or transliteration method, IMO.
>
> Therefore, my proposal is to relax these limitations as much as
> possible (or at least somewhat) and to allow some more freedom when it
> comes to naming packages and other kinds of items in the store. We
> could, of course, still disallow all the main problematic characters,
> such as NUL, /, $, ~, space, newline and a few others, but other than
> that, I don't see any reason to forbid any of the remaining ones from
> being used.
>
> I'd like to hear your opinions on this and get to know whether this
> idea is feasible to implement at all or not, and if not – why?
>
> [0] https://issues.guix.gnu.org/64976
> [1] https://git.savannah.gnu.org/cgit/guix.git/tree/nix/libstore/store-api.cc#n58
> [2] https://raštija.lt/liepa/paslaugos-vartotojams/narsytuvas
> [3] https://gitlab.com/guix-media-channels