On 07.02.21 14:30, 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 an
