From: Nala Ginrut <nalaginrut@gmail.com>
To: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
Cc: Guile User <guile-user@gnu.org>
Subject: Re: Handling modules with same name (from library and from current project)
Date: Mon, 6 Jan 2025 11:38:51 +0900 [thread overview]
Message-ID: <CAPjoZoesodBo6R0SRZTEfBS685WsUqjoAjR-22WO=NiX4xF5nQ@mail.gmail.com> (raw)
In-Reply-To: <93959885-36a6-43d9-9622-ece752a3ad91@posteo.de>
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 <zelphirkaltstahl@posteo.de> 于 2025年1月6日周一 上午10:09写道:
> Hi Nala!
>
> Thank you for your response! I tried it and got that structure working. As
> far as I see the rules are as follows:
>
> (1) prefix with something library specific, so that there are no conflicts
> 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 subdirectory
> 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 be
> 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 to
> 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 module
> 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-name"
> 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 module
> 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 basically
> unusable.
>
> OK, but now I know better how to structure things in Guile projects! Thank
> 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 libraries
> 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 <zelphirkaltstahl@posteo.de> 于 2025年1月5日周日 下午11:50写道:
>
>> Hello Guile Users!
>>
>> I have a question regarding an issue I run into again and again, and have
>> 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 example
>> 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 security
>> 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 least
>> 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 have
>> 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 utilities
>> 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 ...)` manipulations
>> in my
>> code. As far as I know I am not doing anything dirty there. But ... Guile
>> 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. How
>> 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 do
>> something else. In this case build a website thing in Guile. But now I am
>> side
>> tracked again by this issue, because I don't know how to do this properly.
>>
>> Best regards,
>> Zelphir
>>
>> --
>> repositories:
>> https://notabug.org/ZelphirKaltstahl,https://codeberg.org/ZelphirKaltstahl
>>
> --
> repositories: https://notabug.org/ZelphirKaltstahl, https://codeberg.org/ZelphirKaltstahl
>
>
prev parent reply other threads:[~2025-01-06 2:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-05 14:49 Handling modules with same name (from library and from current project) Zelphir Kaltstahl
2025-01-05 15:42 ` Nala Ginrut
2025-01-06 1:08 ` Zelphir Kaltstahl
2025-01-06 2:38 ` Nala Ginrut [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPjoZoesodBo6R0SRZTEfBS685WsUqjoAjR-22WO=NiX4xF5nQ@mail.gmail.com' \
--to=nalaginrut@gmail.com \
--cc=guile-user@gnu.org \
--cc=zelphirkaltstahl@posteo.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).