From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Nala Ginrut Newsgroups: gmane.lisp.guile.user Subject: Re: Handling modules with same name (from library and from current project) Date: Mon, 6 Jan 2025 11:38:51 +0900 Message-ID: References: <22b33143-8fc9-4aa5-b1b5-978ce7f118e6@posteo.de> <93959885-36a6-43d9-9622-ece752a3ad91@posteo.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21988"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Guile User To: Zelphir Kaltstahl Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Mon Jan 06 03:39:44 2025 Return-path: Envelope-to: guile-user@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tUd1r-0005aW-3m for guile-user@m.gmane-mx.org; Mon, 06 Jan 2025 03:39:43 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUd1K-0001V3-FS; Sun, 05 Jan 2025 21:39:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tUd1I-0001Uv-G0 for guile-user@gnu.org; Sun, 05 Jan 2025 21:39:08 -0500 Original-Received: from mail-pj1-x102e.google.com ([2607:f8b0:4864:20::102e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tUd1F-0003rz-Jm for guile-user@gnu.org; Sun, 05 Jan 2025 21:39:08 -0500 Original-Received: by mail-pj1-x102e.google.com with SMTP id 98e67ed59e1d1-2f441904a42so20304876a91.1 for ; Sun, 05 Jan 2025 18:39:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736131144; x=1736735944; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4lEepj9Ut0wFXVI5knfUDlp+156rA3q4ackCDti/Hxk=; b=MU8vPN4RBJo14YRVzFjtVsgMK5i9ofkrg8Bi2aGrkh8aKqjRkCgU6Ddqxy865CkM0j drPmFUfcr3mJFQALF7Odj+/eJmpAvcT13fjQ2q8FW4n1hhwh63ErxEJPRipbADJ+WExI eJEGIBXP4oVTM7wc3WxzjLJSYYmb0Uj1U2+0EYEyFy6d4jv1M6trdYn/nXgBgGonzghL DfBVpNPUHje+6DOdDBpH3u6YnsWpcih62EiWgd3AHP/eBJiYwKwkPSid2BsCM1YIxqEg uZt8aULgNIT3QQD1q4aoyLGJD+lEgG+vcKvkb4kdg3ZlK4pkjWPpNkLgrHtV/xM5GTVh o72w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736131144; x=1736735944; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4lEepj9Ut0wFXVI5knfUDlp+156rA3q4ackCDti/Hxk=; b=EKbNAwtJvPYeNVGL30NpGWM7JZbOSwTg0zyByvjRhZdDxwgNP12EuGRa4zAWy9Tid5 KpbBDQ4d3I0a4anq/MX61NryybGShO7Pky/WaIX+eC5CHrE3lD5nNdDSskqLcdVG5aZb wXvStoBeGpjgskcl70GvjCgpU5AV6YAuBsagk0KBLVgGrAlI2Cq9bFl6fWa2HK74xcxM NqZ/chcX9AbBsv+mRvB8yn3yAHX2T85n7ldH0RLMyvbr4ZS1xa8nQRrES8dMgZOYznXe SF2fIV3YG2IJYyjFC6GxeHV1SWlfzxIj7jWHksq9kEGnfNSfR4qlTd2jeT4PbfI2pHXL n0Ag== X-Gm-Message-State: AOJu0YydYXzRjFMt0QSpZOem+T2GkKZhzwPY+m95OsGn5327YxTMZox1 WMKyPbYHMJXAHpZQabT0J36RsXeIIsTZ3b2F7uHZJV7A4OFqGBYCcpFSjQUxaHTWh/3B0piPcri SbnUPuiWdeZy6VQQE4IdKIkh4yOE= X-Gm-Gg: ASbGncs/thxpTc8tiy+0zrAOejIM6TDQH90uEgOavERmd76iD3FVJ3NIBFekRPk5Pph 9P3zRyfi7hWh9h/yTrM457UXWg8qKzwxqJrxPXUwgqfVe3e5M25tptXmdig4fUoqLIFpPYw== X-Google-Smtp-Source: AGHT+IFq9l6TCohUy0OwJp/9ipOwcAZqMWo5ZwlCXxnA0tN7XSOIWlTeeRrMo6paJweLUZymUswtUtq/DybI2Lsy+Nc= X-Received: by 2002:a17:90b:53cc:b0:2ee:f46f:4d5f with SMTP id 98e67ed59e1d1-2f452dfa485mr78103695a91.6.1736131143810; Sun, 05 Jan 2025 18:39:03 -0800 (PST) In-Reply-To: <93959885-36a6-43d9-9622-ece752a3ad91@posteo.de> Received-SPF: pass client-ip=2607:f8b0:4864:20::102e; envelope-from=nalaginrut@gmail.com; helo=mail-pj1-x102e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.user:20041 Archived-At: Hi Zelphir! For new library, I would recommend to always set a namespace with an unique name directory. However, if you want to reuse an existing library in minimum cost without changing anything, I think renamer in Guile/RnRS module system can help. Personally, I treat the latter a workaround in a lower priority. Best regards. Zelphir Kaltstahl =E4=BA=8E 2025=E5=B9=B41=E6= =9C=886=E6=97=A5=E5=91=A8=E4=B8=80 =E4=B8=8A=E5=8D=8810:09=E5=86=99=E9=81= =93=EF=BC=9A > Hi Nala! > > Thank you for your response! I tried it and got that structure working. A= s > far as I see the rules are as follows: > > (1) prefix with something library specific, so that there are no conflict= s > with other projects/libraries > > (2) In order to not have all the utility modules on the top level of a > project, one can move them into a subdirectory (obviously). Lets say the > subdirectory's name is "libs". But then one needs to add that subdirector= y > to the load path using the `-L` argument of guile (OK, also kind of > obvious), so `guile ... -L libs ...`. > > (3) In order to make ones module named uniquely for the library one is > writing, one should prefix their module names/identifiers. For example > `(define-modules (my-lib-name the-module-name))`. In order for Guile to b= e > able to find such a module however, it has to be inside a folder named > "my-lib-name". That means, that inside ones "libs" directory, one needs t= o > create a folder named "my-lib-name" and move all the modules inside that > folder. > > (4) However! One would be mistaken to now change the load path to `guile > ... -L libs/my-lib-name ...`! The load path still needs to be added as > follows: `guile ... -L libs/ ...`. This seems to be, because Guile takes > each part of the module name, and tries to find a file defining that modu= le > inside a file structure that corresponds to the name. So for finding a > module imported and named `(my-lib-name my-module-name)` Guile would try = to > find it as follows: For each directories on the load path check, if there > is a module "my-module-name" inside a directory "my-lib-name". Since we > added "libs" to the load path, Guile will be able to find the "my-lib-nam= e" > directory inside it. Inside the "my-lib-name" directory, I am guessing, > that it checks all the non-directory files inside, whether any of them > contains a module that has the name `(my-lib-name my-module-name)`. > > Conclusion: > > What I did not check is, whether the file, that contains the actual modul= e > needs to be named "my-module-name.scm" or not. I guess it should not hurt > to name it that way. > > As a consequence of this, I must update my guile-fslib package, if I want > to be able to use it anywhere properly, and its current state is basicall= y > unusable. > > OK, but now I know better how to structure things in Guile projects! Than= k > you! > > Best regards, > Zelphir > On 05.01.25 16:42, Nala Ginrut wrote: > > > How do you > avoid these module name conflicts? How do you make sure that only librari= es > themselves use their own helper function modules? > > If I understand you correctly. > I think you should add a namespace as directory inside lib dir, pick your > own unique project name as the namespace, say mylib, and define it as > (define-module (mylib list-utils)) > > Best regards. > > Zelphir Kaltstahl =E4=BA=8E 2025=E5=B9=B41= =E6=9C=885=E6=97=A5=E5=91=A8=E6=97=A5 =E4=B8=8B=E5=8D=8811:50=E5=86=99=E9= =81=93=EF=BC=9A > >> Hello Guile Users! >> >> I have a question regarding an issue I run into again and again, and hav= e >> not >> found an adequate solution for yet. I want to know how you are handling >> this, >> what your solution is. >> >> (1) recent story: >> >> I have a website, that I wrote manually in pure HTML and CSS. It does >> what it >> should and there is no actual issue with it. However, I have been >> thinking it >> would be cool to implement it in Guile and make a sort of minimal exampl= e >> or web >> "framework", of how one can make such a static website using Guile. I >> already >> have some example in my examples repository. However, that example has >> code in >> it, that is copied from my existing "guile-fslib", which is on guix >> already. So >> I have been thinking: "I should just install the package from guix and >> remove >> this code from my new website repository, having it hidden away in the >> guile-fslib library." It is just some code to work with file names and >> directories and paths, not directly web related, but important for >> checking, >> whether a request for a static resource/an asset is within the "static" >> directory, and not just anywhere on the server, which would be a securit= y >> issue. >> >> Of course I could put everything in a docker container or something, or >> completely serve static assets using a HTTP server, as one should, but >> then the >> Guile thing I want to build would not work on its own. I want to at leas= t >> have >> it implemented as a fallback, so that one could run it without an >> additional >> thing in front of it for handling static resource requests. >> >> (2) So far so good. But now comes the problem: >> >> "guile-fslib" has a module named "string-utils" and a module named >> "list-utils". >> In my guile web development example code I also have modules with those >> names. >> Guile then gets confused about which one I am referring to, when I >> `(use-modules >> ...)` them and in the code that makes use of the functions from those >> modules, >> it then claims, that no bindings with some name exist, because it has >> looked >> into the "list-utils" or "string-utils" of the guix package, instead of >> the one >> of my web project. >> >> (3) Thoughts: >> >> I don't know how to resolve this. I think it is very unreasonable to hav= e >> to >> look out to name no module the same name as any module in any library I >> am >> using. Obviously many libraries or projects will have some list utilitie= s >> or >> helpers for convenience. Many projects will have some special string >> functions. >> Having a name like "string-utils" or "string-helpers" should not be an >> impossibility. >> >> From a past/previous case of this, I remember someone saying I should >> get my >> load path in order. But what does this mean? In my projects I invoke >> Guile doing >> something like this: >> >> ~~~~ >> guile -L . -L libs main.scm >> ~~~~ >> >> I simply use the `-L` argument to pass in all the directories, in which >> my >> modules reside, for example "libs/list-utils.scm" or >> "libs/string-utils.scm", >> which I then import into various other modules and the main file, the >> entrypoint. >> >> (4) Solution ideas: >> >> (4.1) I already abstain from doing `(add-to-load-path ...)` manipulation= s >> in my >> code. As far as I know I am not doing anything dirty there. But ... Guil= e >> gets >> confused about which module to import and it seems to see the one from >> installed >> library first and then not consider the one of my current project. I am >> not even >> sure how Guile could possibly know which module I am referring to, >> because I am >> not telling it anything about that. So I am wondering, whether some dark >> magic >> of dynamically changing load path is perhaps a _necessary_ evil? >> >> (4.2) Or perhaps I have to give my modules multi part names like >> `(define-module >> (fslib helpers list-utils))` to scope module names? But that would be >> annoying >> when using them inside the library itself, because it is more to write >> and I am >> not sure others are doing that always. Usually I just name my modules >> `(list-utils)` or `(string-utils)`. Is that a bad thing, when these are >> modules >> of helper functions, which are not supposed to be exported for use in >> other >> projects? >> >> (4.3) The ugly solution I so far had to reach for, because I couldn't >> figure out >> a better way: Integrate library code directly into the source tree of a >> project, >> copying code. This cannot be the right way to do it, can it? Seems >> unlikely. >> >> How do you manage this? I know people have written much bigger projects >> than I >> have and surely someone has some dependency on another Guile library. Ho= w >> do you >> avoid these module name conflicts? How do you make sure that only >> libraries >> themselves use their own helper function modules? >> >> The bad thing is, that I always run into this, when I actually want to d= o >> something else. In this case build a website thing in Guile. But now I a= m >> side >> tracked again by this issue, because I don't know how to do this properl= y. >> >> Best regards, >> Zelphir >> >> -- >> repositories: >> https://notabug.org/ZelphirKaltstahl,https://codeberg.org/ZelphirKaltsta= hl >> > -- > repositories: https://notabug.org/ZelphirKaltstahl, https://codeberg.org/= ZelphirKaltstahl > >