unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* guile-hall issues converting my project to a hall project
@ 2021-02-06 21:49 Zelphir Kaltstahl
  2021-02-07  9:14 ` tomas
                   ` (2 more replies)
  0 siblings, 3 replies; 15+ messages in thread
From: Zelphir Kaltstahl @ 2021-02-06 21:49 UTC (permalink / raw)
  To: Guile User

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-package-using-guile-hall
commit:
https://notabug.org/ZelphirKaltstahl/guile-fslib/src/a8344c5dd47515c533af3ebd497adcce6b683e82),
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

-- 
repositories: https://notabug.org/ZelphirKaltstahl




^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2021-02-23 16:32 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-06 21:49 guile-hall issues converting my project to a hall project Zelphir Kaltstahl
2021-02-07  9:14 ` tomas
2021-02-07 13:30 ` Tim Van den Langenbergh
2021-02-11 20:30   ` Zelphir Kaltstahl
2021-02-16  0:23   ` Zelphir Kaltstahl
2021-02-17 22:47     ` Vladimir Zhbanov
2021-02-18 12:18       ` alex sassmannshausen
     [not found] ` <11206998.46ALo4VoAQ@terra>
     [not found]   ` <02902ff9-1585-a453-4e36-c9a731eee6fe@posteo.de>
2021-02-16 16:48     ` Tim Van den Langenbergh
2021-02-16 18:12       ` Zelphir Kaltstahl
2021-02-17 21:17         ` Alex Sassmannshausen
2021-02-18 19:16           ` Zelphir Kaltstahl
2021-02-21 13:42             ` Alex Sassmannshausen
2021-02-22 11:34               ` guile-hall packaging guide Zelphir Kaltstahl
2021-02-22 20:52                 ` Jérémy Korwin-Zmijowski
2021-02-23 16:32                   ` Alex Sassmannshausen

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).