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 <zelphirkaltst...@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
