From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Van den Langenbergh Newsgroups: gmane.lisp.guile.user Subject: Re: guile-hall issues converting my project to a hall project Date: Sun, 07 Feb 2021 14:30:19 +0100 Message-ID: <2433258.t1ASBiXS4l@terra> References: 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="32893"; mail-complaints-to="usenet@ciao.gmane.io" Cc: guile-user@gnu.org To: Zelphir Kaltstahl Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Sun Feb 07 14:31:16 2021 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 1l8k9j-0008Sk-82 for guile-user@m.gmane-mx.org; Sun, 07 Feb 2021 14:31:15 +0100 Original-Received: from localhost ([::1]:56540 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l8k9i-0004lT-AH for guile-user@m.gmane-mx.org; Sun, 07 Feb 2021 08:31:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34378) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l8k91-0004kd-TG for guile-user@gnu.org; Sun, 07 Feb 2021 08:30:31 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:41207) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l8k8w-0000u6-Ir for guile-user@gnu.org; Sun, 07 Feb 2021 08:30:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1612704620; bh=8UCIxduuAIj4EYE1IxKjD146XKaJ2c5BhZFfwaeAlhw=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=fLVnnC2XSIek4SHONoIg2SCdX6IpMBlV9HoXP//r+ZgwVzqMzvUku9c1DhOf1ZMV6 t4HGh61EqrTc82cD2N/AIjPbnslE5WvhkHOLuMirQDvocPJW7WkhJKUaTj42FPXhp5 SXC1uD57TH26PUz+bkrhCSfaicke2+WiCzXJKMeA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from terra.localnet ([94.227.125.226]) by mail.gmx.net (mrgmx105 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MA7KU-1lEkPW1OzC-00BZkY; Sun, 07 Feb 2021 14:30:20 +0100 In-Reply-To: X-Provags-ID: V03:K1:U3AfrSHX9aqGogBcxyqR+lGlhoCgZLfM6AkgoZ22xj40gowKghJ HqGLOS3v9lEleAsynBGQ1W7oEwplnMUSKJqOqDKkjXhhUndFi3QUQnRmNxeqd+ffSfMk6ab UDx7LrqFRO7PLJwen2rQkYv2y2mv51D3TcoDG1U1Oaz9E1uVKNDXGZrVoaMZLJLCkGv/ZOu wB3dDx1vn8VbWmL7fPhUA== X-UI-Out-Filterresults: notjunk:1;V03:K0:FK3BVpJZ0YE=:SkfdnySGnGFn8T+Sedqfqe zN5evZjDnx/cfpWDQWgFna+VCqCPR5qvx9b206fSSHe55yxll6A+4TMHhG5e7U9LzeWRIsHO1 X5Y+qDL0r/j0S6wlhKx/l8tKrLppHgOokqJmzauXvJBzNrHGeRw/CxbjkxR8uPDPxjR85Ogel PlzW49OojqNyWenvxFr5lLkorQVhZyzGWC+1i2kjwFK6ySjZALH+HArNqg4GVqPQoIL8cmkSB eWc3SopNcZ/42XarAQZLtVyqIVYntTUK+doNR9uBQFuz8tvZyD5QI0Hn1Uy7mhZaUUs5W91Ft sEFoLWNjB9CSvjJPEer5GaEJ29Nk4x6He5IlzweKWT3teeECAu3KhA7Tj+y6z5hSykyKxfeSo CbFPb4/+a/JeINtcY7PpXEkGl63UZ1kil7RZxJ3fFxVdG7Qryd0kacHNBHxIssLcNz41NGWUc TXoM75tB6KQZPOu+/R0EcW2ozH4dx8KbwPW9lZ88JxzMty1RsPsjKX2etdw6ZYvZaAGl71TRl j9FcebVW9IdWJ0IfBwcuW7g1RpLqsSojCwZm5UyzVNI8PfUJDIbVSBLdVP0CNMG+eHdQfpMbO rpdiRaoT5pP5mnuE0Gvl+TCe5lJKDfff6qbxp1u+XpbSf58YMt/zLE7b5CpnqmdNC62ij/FYJ hO32P7gQRkWVdJEy9SMpwpwrr6loHCCQAGi7kXnOhXM9KoLO6qOSx6otbLG2vAR/361M+BzRI mOE32Pu35obZtJJp4t7WpK4q8XZTvfHfvTI/osLa43BzJxNn4vJwNRYl2UDnyQeFw1tPsH+2 Received-SPF: pass client-ip=212.227.17.22; envelope-from=tmt_vdl@gmx.com; helo=mout.gmx.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.lisp.guile.user:17232 Archived-At: On Saturday, 6 February 2021 22:49:12 CET Zelphir Kaltstahl wrote: > Hello Guile Users! >=20 > I decided to try to use guile-hall to convert my project at > https://notabug.org/ZelphirKaltstahl/guile-fslib into a Guix package. > For that purpose I created a separate branch > "wip-guix-package-using-guile-hall" > (branch: https://notabug.org/ZelphirKaltstahl/guile-fslib/src/wip-guix-pa= cka > ge-using-guile-hall commit: > https://notabug.org/ZelphirKaltstahl/guile-fslib/src/a8344c5dd47515c533af= 3eb > d497adcce6b683e82), from which I am starting to run commands. >=20 > It seems, that many of guile-hall's defaults are wrong for my project > and I need to adapt a lot of its settings. It also tells me to report > unsupported file types, but I cannot do that in the guile-hall > repository, because I cannot log in on Gitlab, because Gitlab has a > "clever" "check of my browser", which simply loops forever reloading the > "browser check" website =E2=80=A6 My guess: The check requires third party > cookies to be set. So I am going to write about it here and hope someone > knows how to proceed. >=20 > The example call in the readme of > https://gitlab.com/a-sassmannshausen/guile-hall for converting a project = is: >=20 > ~~~~ > hall init --convert --author "Jane Doe" --prefix guile frobnigator --exec= ute > ~~~~ >=20 > I am not sure what exactly the prefix is. `hall init --help` only tells > me: "Prefix of the project.", which does not help me. It basically has > zero more information for me. Does this already have to do with the > Makefile, which is created later? I leave prefix at "guile" for now. > What is "frobnigator"? I think it is the name of the project, because in > `hall init --help` it says that the syntax is: >=20 > ~~~~ > hall initiate [-cx] NAME > [-a "Alyssa P. Hacker"] > [-l gpl3+] > [-p guile] > [-w "https://website.mine"] > ~~~~ >=20 > (I like the SICP reference, btw.) `NAME` is the only thing that I cannot > translate anything else to be in the command above. I think it would be > better to not use something confusing like "frobnigator", which people > might not know what that even is, and use a generic word like > "my-project-name". >=20 > So the command I run is: >=20 > ~~~~ > hall init --convert --author 'Zelphir Kaltstahl' --prefix 'guile' fslib > --license 'agpl3+' --execute ~~~~ >=20 > What I like about it is, that everything seems to be dry-run, except > when adding `--execute`. That makes things less scary. >=20 > Then hall creates a bunch of files, but most things seem not to consider > my actual already existing project structure. hall never asks me what my > test directory is or what file my license information is in. I think it > would be good to have those things available as command line arguments, > so that I do not need to fix things afterwards, which differ from the > defaults. >=20 > I will list the things, that I need to change to correct values after > the hall command has finished and steps I am taking, from the > perspective of a first time user, because perhaps it can help improving > guile-hall: >=20 > (1) Remove my old license file, which was not `COPYING` but `LICENSE`. > Here I do not really care about in which file it is. It would be great, > if hall asked me about the `LICENSE` file though. Perhaps a list of > common names of license files could be added to hall and it could check > for those? >=20 > (2) In `guix.scm` the version is wrong. It should be `(version > "0.2.0")`, not `(version "0.1")`. The git repository already has a tag > `0.2.0`, but I think, that "0.1" is a default value, which is simply put > into `guix.scm`. Here a `--version` argument would be good to have, with > the default still being `0.1.0` or `0.1`. I think 3 parts is the better > choice, because it makes processing version numbers easier. Every > version number would have 3 parts. Always. And it could be made a list > of 3 symbols or even numbers as well. But if they are only numbers, one > could not have something like "rc" for release candidate or stuff like > that. Also not everyone might want to use version numbers like these. I > have seen projects using the date as version number. >=20 > (3) After adapting the version number, the `source` has to be adapted as > well to reflect the change in version. At this point I get insecure > about the whole thing. "Will Guix be able to find this archive? Will it > look only for a version number consisting of 2 parts? Will anything > break later in the process, because I am not following the same > versioning syntax and have 3 parts instead of 2 parts written in the > string?" >=20 > (4) In the `guix.scm` native inputs are defined. The concept of that is > very unclear in my mind. I read about that previously on the Guix pages, > but I already forgot again what native inputs are and how they differ > from inputs. Anyway, probably not so important right now. However, they > list "texinfo". My project does not make use of texinfo at all. But I am > insecure now about removing it. Perhaps hall will not be able to deal > with it, if I remove it, so I am leaving it there for now. Hopefully I > can remove it later and make my dependencies fewer (?). >=20 > (5) In `hall.scm` the version is wrong as well. As in `guix.scm`, I > change it to the correct version. >=20 > (6) Next is the `files` section. This one creates a lot of insecurity. > It says `(directory "fslib" ())`. I have not put my source files into a > directory `fslib`, but I had no chance to tell hall, that there is no > such thing beforehand. If I have to move all my source files, then I > also need to change all my imports! My source files are in the root > directory of the project. I've had no need so far to move them into a > subdirectory. I guess with all the project managing files hall created, > a subdirectory makes sense, but then I am changing my code to conform to > what hall wants the structure to be and I am not telling hall what kind > of structure my project has instead, to make it figure out how to write > the makefiles etc. So this is one of the points, where I think it would > be good to give hall an argument `--source-location '.'` or something > like that. I will try to adapt the configuration by changing the > `directory` to "." instead of "fslib". More insecurity: "Will hall be > able to work with that? Will it understand "."? Or will everything break?" >=20 > (7) The tests directory is wrong. I have my tests in `test`, without the > plural "s". I will change the setting. >=20 > (8) I do not have additional `programs` in this project. Can I simply > remove this entry from the hall settings? I better leave it in there, > hall might break, if unexpectedly that setting is missing. >=20 > (9) I do not know what to do now, that hall has created all these files > and I have corrected some of the values in its settings. At this point I > am asking myself, whether I somehow need to generate any of the files > anew. But I find the `HACKING` file and see that in there it says I can > activate a Guix environment now, from the files hall produced: >=20 > ~~~~ > guix environment -l guix.scm > ~~~~ >=20 > And that still works, even though I changed stuff in there. Good! >=20 > (10) Next comes the important step it seems: >=20 > ~~~~ > hall dist --execute && autoreconf -vif && ./configure && make check > ~~~~ >=20 > `hall dist`. According to `hall dist --help` it will create the build > system files, which I am guessing are all the files for GNU Automake and > GNU Make and so on. >=20 > I forgot what autoreconf did again. >=20 > `./configure` checks for stuff in my system to be available or not, to > reason about whether the thing will build or not and collect locations > of required binaries etc. >=20 > `make check` probably runs my tests. >=20 > Everything runs through, there is a lot of output. It only shows `GEN > fslib.go` though, none of the other modules are shown. Probably because > I have not run `hall scan` yet. >=20 > (11) `hall scan`. This gets me to the first real error: >=20 > ~~~~ > $ hall scan >=20 > Your project contains a file (traces.1) of a type that is not supported by > Hall yet. (unknown-file). Please report this at our website > ~~~~ >=20 > OK I cannot do that, because Gitlab does not let me in. Fine, where is > that file? `find . -name 'traces.1'` reveals: > `./autom4te.cache/traces.1`. Why does it look into the cache it created > itself? I did never create the file and the folder it is in. Is there > some ignore file for hall, like `.gitignore`, where I need to add the > cache folder to? OK, it is a cache folder, so I will simply delete it > and run `hall scan` again. >=20 > ~~~~ > $ rm -rf autom4te.cache > $ hall scan >=20 > Your project contains a file (pre-applypatch.sample) of a type that is not > supported by Hall yet. (unknown-file). Please report this at our website > ~~~~ >=20 > Damn, another file it does not support! Where is it this time? Oh no =E2= =80=A6 > It is inside `.git`! But why does it complain about that?! It is normal > to have the .git folder at the top level. I cannot remove that. Git hook > sample files are there by default. Perhaps I can remove the sample hook > files and then try again =E2=80=A6 >=20 > =E2=80=A6 Now it complains about my tag files in .git! It seems I cannot = run > `hall scan` successfully. >=20 > This is it so far. This is as far as I got and I have no idea, whether I > am anywhere close to a functioning package. >=20 > Can you help me out? How do I proceed from here? Please assume no > knowledge about "things that are obvious" about any of guile-hall or > autotools, automake, make and the like. >=20 > Do I really have to move my source files into the directory hall created > and change all my import expressions in the source code? That can be > arranged. Although this seems to hint at an unfortunate coupling of > project name and directory in which source files reside. Similar to what > docker-compose is doing with container names and the folder inside which > you run it. Such a thing can be quite annoying. >=20 > How do I fix that "unsupported file type" thing? >=20 > I feel like there are so many files and stuff hall added, that if only I > understood more about what exactly GNU Guix _must_ find in the project > directory to use it as a package, I might be better off creating that > stuff manually, but perhaps to make a package I must have all this > stuff? I have no idea, whether the license must be in COPYING, or having > it inside LICENSE is fine too. I think I will ask for a complete list of > all things required by Guix on the Guix mailing list. The verdict is not > out yet though. I still hope to make everything work with guile-hall, > hoping anyone can help. >=20 > Best regards, > Zelphir Hi Zelphir, the prefix is a part of the project name that you do not want to include in= the=20 name of whichever module/library you are making, for example if I want to m= ake=20 a project called "Guile-Utils" which exports a library called "utils" I wou= ld=20 use the prefix argument to add "guile" in front. Without it I could make a= =20 library called "utils" but hall would complain if I didn't have a library=20 called "guile-utils" as well. You also raised various good points, especially about what a pain it is to = run=20 hall scan after running hall dist (which we really should warn people not t= o=20 do). Basically the way to think of hall is like an inverse git, where instead of= =20 excluding certain files with a .gitignore, you keep track of files through = your=20 hall.scm. If you don't want to restart the conversion of your project to a hall proje= ct=20 from scratch I fear you may have to edit your hall.scm by hand. =46eel free to contact me if you have more questions. Vale, =2DTim Van den Langenbergh