From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Zelphir Kaltstahl Newsgroups: gmane.lisp.guile.user Subject: Re: guile-hall issues converting my project to a hall project Date: Thu, 11 Feb 2021 21:30:52 +0100 Message-ID: <8c8145e2-d751-5fde-5848-2082ca306dd0@posteo.de> References: <2433258.t1ASBiXS4l@terra> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37045"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cc: guile-user@gnu.org To: Tim Van den Langenbergh Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Thu Feb 11 21:31:58 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 1lAId3-0009UO-9f for guile-user@m.gmane-mx.org; Thu, 11 Feb 2021 21:31:57 +0100 Original-Received: from localhost ([::1]:46442 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lAId1-0001wF-IT for guile-user@m.gmane-mx.org; Thu, 11 Feb 2021 15:31:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39386) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAIcE-0001vB-Cn for guile-user@gnu.org; Thu, 11 Feb 2021 15:31:09 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]:49478) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAIc6-0005bY-Ri for guile-user@gnu.org; Thu, 11 Feb 2021 15:31:04 -0500 Original-Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 9C51416005F for ; Thu, 11 Feb 2021 21:30:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1613075453; bh=XI9dolwlZRVPAOFOuwVVdrPymF54NMV3OwKo1RkJ7Dc=; h=Subject:To:Cc:From:Date:From; b=OAFPXvOkdZalYmRWR/kr92CqjK04GhZn/UuM4+qoAB15vY4n3g+L/1WWaoxG5cXcK r0mN0aziswUiVaUu59cOZqc98oUaldRb1N1/o3xz9vt3zHZJMWi3gVTlZqbMkQ6rTP +6ZFGtRYH5r84/8QBztDba3Gx63LD9FazQtnj8J/erdQvG7AlC2p+YSeFscnPpiM2n 80oFGcRjeTNVieI4EUi9tYlF7QeWqSl42yqxzpSe78bEEgsf8BQhWCm83JH9mhEna4 MpxYKZYCwJVy7fLVOMVS6oAepd1AQh3phUW+2keekGCssBP3z3ab9UplgW01YTrJ3v xO8igoRj/XUkw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Dc7Ym5lxZz6tmP; Thu, 11 Feb 2021 21:30:52 +0100 (CET) X-Tagtoolbar-Keys: D20210211213052021 In-Reply-To: <2433258.t1ASBiXS4l@terra> Content-Language: en-US Received-SPF: pass client-ip=185.67.36.65; envelope-from=zelphirkaltstahl@posteo.de; helo=mout01.posteo.de X-Spam_score_int: -44 X-Spam_score: -4.5 X-Spam_bar: ---- X-Spam_report: (-4.5 / 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, NICE_REPLY_A=-0.119, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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:17242 Archived-At: On 2/7/21 2:30 PM, Tim Van den Langenbergh wrote: > On Saturday, 6 February 2021 22:49:12 CET Zelphir Kaltstahl wrote: >> Hello Guile Users! >> >> 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-packa >> ge-using-guile-hall commit: >> https://notabug.org/ZelphirKaltstahl/guile-fslib/src/a8344c5dd47515c533af3eb >> d497adcce6b683e82), from which I am starting to run commands. >> >> 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 … 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. >> >> The example call in the readme of >> https://gitlab.com/a-sassmannshausen/guile-hall for converting a project is: >> >> ~~~~ >> hall init --convert --author "Jane Doe" --prefix guile frobnigator --execute >> ~~~~ >> >> 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: >> >> ~~~~ >> hall initiate [-cx] NAME >> [-a "Alyssa P. Hacker"] >> [-l gpl3+] >> [-p guile] >> [-w "https://website.mine"] >> ~~~~ >> >> (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". >> >> So the command I run is: >> >> ~~~~ >> hall init --convert --author 'Zelphir Kaltstahl' --prefix 'guile' fslib >> --license 'agpl3+' --execute ~~~~ >> >> What I like about it is, that everything seems to be dry-run, except >> when adding `--execute`. That makes things less scary. >> >> 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. >> >> 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: >> >> (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? >> >> (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. >> >> (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?" >> >> (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 (?). >> >> (5) In `hall.scm` the version is wrong as well. As in `guix.scm`, I >> change it to the correct version. >> >> (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?" >> >> (7) The tests directory is wrong. I have my tests in `test`, without the >> plural "s". I will change the setting. >> >> (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. >> >> (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: >> >> ~~~~ >> guix environment -l guix.scm >> ~~~~ >> >> And that still works, even though I changed stuff in there. Good! >> >> (10) Next comes the important step it seems: >> >> ~~~~ >> hall dist --execute && autoreconf -vif && ./configure && make check >> ~~~~ >> >> `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. >> >> I forgot what autoreconf did again. >> >> `./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. >> >> `make check` probably runs my tests. >> >> 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. >> >> (11) `hall scan`. This gets me to the first real error: >> >> ~~~~ >> $ hall scan >> >> 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 >> ~~~~ >> >> 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. >> >> ~~~~ >> $ rm -rf autom4te.cache >> $ hall scan >> >> 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 >> ~~~~ >> >> Damn, another file it does not support! Where is it this time? Oh no … >> 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 … >> >> … Now it complains about my tag files in .git! It seems I cannot run >> `hall scan` successfully. >> >> 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. >> >> 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. >> >> 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. >> >> How do I fix that "unsupported file type" thing? >> >> 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. >> >> Best regards, >> Zelphir > Hi Zelphir, > > the prefix is a part of the project name that you do not want to include in the > name of whichever module/library you are making, for example if I want to make > a project called "Guile-Utils" which exports a library called "utils" I would > use the prefix argument to add "guile" in front. Without it I could make a > library called "utils" but hall would complain if I didn't have a library > called "guile-utils" as well. > > You also raised various good points, especially about what a pain it is to run > hall scan after running hall dist (which we really should warn people not to > do). > > Basically the way to think of hall is like an inverse git, where instead of > excluding certain files with a .gitignore, you keep track of files through your > hall.scm. > > If you don't want to restart the conversion of your project to a hall project > from scratch I fear you may have to edit your hall.scm by hand. > > Feel free to contact me if you have more questions. > > Vale, > > -Tim Van den Langenbergh Hello Tim, Thank you for explaining the prefix thing. I think that makes sense in combination with GNU Guix, as GNU Guix has the convention of prefixing package names with the programming language. Also thanks for mentioning, that one is not supposed to run hall scan after hall dist. I do not mind editing guix.scm or hall.scm, as long as the do-s and do-not-s are clear and I can understand it. I hope to look into making a new hall project and then incrementally adding my existing library to it. I'll keep you in mind, if questions arise. Thanks, Zelphir -- repositories: https://notabug.org/ZelphirKaltstahl