* 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
* Re: guile-hall issues converting my project to a hall project 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 [not found] ` <11206998.46ALo4VoAQ@terra> 2 siblings, 0 replies; 15+ messages in thread From: tomas @ 2021-02-07 9:14 UTC (permalink / raw) To: guile-user [-- Attachment #1: Type: text/plain, Size: 328 bytes --] On Sat, Feb 06, 2021 at 10:49:12PM +0100, Zelphir Kaltstahl wrote: > Hello Guile Users! Hi, Zelphir not that I could help you in any way wrt. your guile-hall quest, but thanks for your long and detailed report. Way better than silently cursing at the screen and drinking too much coffe ;-) An example to follow. Cheers - t [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: guile-hall issues converting my project to a hall project 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 [not found] ` <11206998.46ALo4VoAQ@terra> 2 siblings, 2 replies; 15+ messages in thread From: Tim Van den Langenbergh @ 2021-02-07 13:30 UTC (permalink / raw) To: Zelphir Kaltstahl; +Cc: guile-user 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: guile-hall issues converting my project to a hall project 2021-02-07 13:30 ` Tim Van den Langenbergh @ 2021-02-11 20:30 ` Zelphir Kaltstahl 2021-02-16 0:23 ` Zelphir Kaltstahl 1 sibling, 0 replies; 15+ messages in thread From: Zelphir Kaltstahl @ 2021-02-11 20:30 UTC (permalink / raw) To: Tim Van den Langenbergh; +Cc: guile-user 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: guile-hall issues converting my project to a hall project 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 1 sibling, 1 reply; 15+ messages in thread From: Zelphir Kaltstahl @ 2021-02-16 0:23 UTC (permalink / raw) To: Tim Van den Langenbergh; +Cc: guile-user 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 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 and hello Guile users! I finally got around to reproducing your patch step-by-step. I have tried to make the commits as "atomic" as possible, so that one can see each step I took in a separate commit. The result is here: https://notabug.org/ZelphirKaltstahl/guile-fslib/src/65d40a0f1dd4bb2005d3f369928ebf5b2247eacc. Now however, I am hitting an issue. When I run: ~~~~ hall dist --execute && autoreconf -vif && ./configure && make check ~~~~ as indicated in the autogenerated HACKING file, I get an error deep in the generated `configure` file: ~~~~ $ hall dist --execute && autoreconf -vif && ./configure && make check Making file: /home/user/dev/Guile/guile-fslib/NEWS Making file: /home/user/dev/Guile/guile-fslib/AUTHORS Making file: /home/user/dev/Guile/guile-fslib/ChangeLog Making dir: /home/user/dev/Guile/guile-fslib/build-aux Making file: /home/user/dev/Guile/guile-fslib/build-aux/test-driver.scm Making file: /home/user/dev/Guile/guile-fslib/configure.ac Making file: /home/user/dev/Guile/guile-fslib/Makefile.am Making file: /home/user/dev/Guile/guile-fslib/pre-inst-env.in autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I m4 aclocal: warning: couldn't open directory 'm4': No such file or directory autoreconf: configure.ac: tracing autoreconf: configure.ac: not using Libtool autoreconf: running: /usr/bin/autoconf --force autoreconf: configure.ac: not using Autoheader autoreconf: running: automake --add-missing --copy --force-missing configure.ac:11: installing 'build-aux/install-sh' configure.ac:11: installing 'build-aux/missing' Makefile.am: installing './INSTALL' Makefile.am: installing './COPYING' using GNU General Public License v3 file Makefile.am: Consider adding the COPYING file to the version control system Makefile.am: for your code, to avoid questions about which license your project uses Makefile.am:62: installing 'build-aux/mdate-sh' Makefile.am:62: installing 'build-aux/texinfo.tex' Makefile.am:63: warning: user target 'dvi' defined here ... automake: ... overrides Automake target 'dvi' defined here Makefile.am:63: consider using dvi-local instead of dvi autoreconf: Leaving directory `.' checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes ./configure: line 2385: syntax error near unexpected token `3.0' ./configure: line 2385: `GUILE_PKG(3.0 2.2 2.0)' ~~~~ The line in the generated `configure` file looks quite simple. It is only: ~~~~ GUILE_PKG(3.0 2.2 2.0) ~~~~ It looks like there could be a simple fix, but I do not know what to do about this error and how that error could happen in the first place. To be sure I also tried the same with your patch applied to the commit, where I had not yet done any steps with guile-hall, but the result and error remains the same. How can I fix this error? Best regards, Zelphir -- repositories: https://notabug.org/ZelphirKaltstahl ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: guile-hall issues converting my project to a hall project 2021-02-16 0:23 ` Zelphir Kaltstahl @ 2021-02-17 22:47 ` Vladimir Zhbanov 2021-02-18 12:18 ` alex sassmannshausen 0 siblings, 1 reply; 15+ messages in thread From: Vladimir Zhbanov @ 2021-02-17 22:47 UTC (permalink / raw) To: guile-user Hi Zelphir, On Tue, Feb 16, 2021 at 01:23:34AM +0100, Zelphir Kaltstahl wrote: ... > The line in the generated `configure` file looks quite simple. It is only: > > ~~~~ > GUILE_PKG(3.0 2.2 2.0) > ~~~~ > It looks like there could be a simple fix, but I do not know what to do > about this error and how that error could happen in the first place. IIUC, the macro args should be in square brackets: GUILE_PKG([3.0 2.2 2.0]) -- Vladimir ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: guile-hall issues converting my project to a hall project 2021-02-17 22:47 ` Vladimir Zhbanov @ 2021-02-18 12:18 ` alex sassmannshausen 0 siblings, 0 replies; 15+ messages in thread From: alex sassmannshausen @ 2021-02-18 12:18 UTC (permalink / raw) To: Guile User Yes, I forgot to mention this in my wall of text. Vladimir's solution is correct. Hall does this in master too. Alex On Wed, 17 Feb 2021, 23:47 Vladimir Zhbanov, <vzhbanov@gmail.com> wrote: > > Hi Zelphir, > > On Tue, Feb 16, 2021 at 01:23:34AM +0100, Zelphir Kaltstahl wrote: > ... > > > The line in the generated `configure` file looks quite simple. It is > only: > > > > ~~~~ > > GUILE_PKG(3.0 2.2 2.0) > > ~~~~ > > > It looks like there could be a simple fix, but I do not know what to do > > about this error and how that error could happen in the first place. > > IIUC, the macro args should be in square brackets: > > GUILE_PKG([3.0 2.2 2.0]) > > -- > Vladimir > > ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <11206998.46ALo4VoAQ@terra>]
[parent not found: <02902ff9-1585-a453-4e36-c9a731eee6fe@posteo.de>]
* Re: guile-hall issues converting my project to a hall project [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 0 siblings, 1 reply; 15+ messages in thread From: Tim Van den Langenbergh @ 2021-02-16 16:48 UTC (permalink / raw) To: Zelphir Kaltstahl; +Cc: guile-user Err, looking at your hall.scm file, you have the fslib file added to your libraries twice. Guix environment is not needed if you have all the requirements for building the package installed locally, but if you want to distribute your package it's good practise to ensure it builds in a clean environment (see also https:// guix.gnu.org/manual/en/html_node/Invoking-guix-environment.html for more information about Guix environments). The "COPYING" file is hardcoded as license file in Hall, to ensure compatibility with GNU standards: https://www.gnu.org/licenses/gpl-howto.en.html Hope this helps, Vale -Tim ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: guile-hall issues converting my project to a hall project 2021-02-16 16:48 ` Tim Van den Langenbergh @ 2021-02-16 18:12 ` Zelphir Kaltstahl 2021-02-17 21:17 ` Alex Sassmannshausen 0 siblings, 1 reply; 15+ messages in thread From: Zelphir Kaltstahl @ 2021-02-16 18:12 UTC (permalink / raw) To: Tim Van den Langenbergh; +Cc: guile-user Hello Tim! Thank you, it works now! Removing the duplicate entry of `fslib` in hall.scm fixed it. Regarding the license: OK, I have no problem moving my license to `COPYING`. However, I still think, that it should not put GPL there, when I specified AGPL in `hall.scm`. This looks like a hardcoded fallback, which does not take the license specification into account. Something like: "If there is no `COPYING` file just put GPL into a file `COPYING`." instead of "If there is no `COPYING` file just put <user-specified-license-in-hall.scm> into a file `COPYING`.". I could be wrong though, as I do not know anything about guile-hall's internals. Follow up question would be, how to bring the package into the guix repository, but I am guessing, that it will be answered at https://guix.gnu.org/cookbook/en/html_node/Direct-checkout-hacking.html, which I have not read yet. Another question is, whether I should put you into the authors file and write something like "help with packaging" there. What is the common practice? Best regards, Zelphir On 2/16/21 5:48 PM, Tim Van den Langenbergh wrote: > Err, looking at your hall.scm file, you have the fslib file added to your > libraries twice. > > Guix environment is not needed if you have all the requirements for building > the package installed locally, but if you want to distribute your package it's > good practise to ensure it builds in a clean environment (see also https:// > guix.gnu.org/manual/en/html_node/Invoking-guix-environment.html for more > information about Guix environments). > > The "COPYING" file is hardcoded as license file in Hall, to ensure compatibility > with GNU standards: https://www.gnu.org/licenses/gpl-howto.en.html > > Hope this helps, > > Vale > > -Tim > > -- repositories: https://notabug.org/ZelphirKaltstahl ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: guile-hall issues converting my project to a hall project 2021-02-16 18:12 ` Zelphir Kaltstahl @ 2021-02-17 21:17 ` Alex Sassmannshausen 2021-02-18 19:16 ` Zelphir Kaltstahl 0 siblings, 1 reply; 15+ messages in thread From: Alex Sassmannshausen @ 2021-02-17 21:17 UTC (permalink / raw) To: Zelphir Kaltstahl; +Cc: guile-user [-- Attachment #1: Type: text/plain, Size: 3662 bytes --] Hi Zelphir and Tim, I am the author of guile hall — apologies for only now getting into this thread. I'm afraid I have been somewhat distracted with other things. First of all I want to echo what others have said — thank you very much for your detailed descriptions of what exactly happened when you tried to migrate the project to guile hall. The aim of the project is to massively reduce the barrier of entry to creating new, portable, high quality guile projects — and to contribute them to Guix. Your descriptions suggest it's not there yet! In any case, some comments inline: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes: > Hello Tim! > > Thank you, it works now! > > Removing the duplicate entry of `fslib` in hall.scm fixed it. Fwiw, since commit ac76541a this issue can be automatically resolved by running scan once more: it should remove duplicate entries in hall.scm. > Regarding the license: OK, I have no problem moving my license to > `COPYING`. However, I still think, that it should not put GPL there, > when I specified AGPL in `hall.scm`. This looks like a hardcoded > fallback, which does not take the license specification into account. > Something like: "If there is no `COPYING` file just put GPL into a file > `COPYING`." instead of "If there is no `COPYING` file just put > <user-specified-license-in-hall.scm> into a file `COPYING`.". I could be > wrong though, as I do not know anything about guile-hall's internals. This is odd — Hall should respect your license choice. It should, for (A)GPL licenses automatically download those from the internet and install them in COPYING. There was an issue with those licenses hiding behind a 302 status code, which resulted in fallback text being loaded in COPYING. But even that fallback text should respect your license. I just tried changing my license to AGPLv3+ in one of my projects, running hall from Master (the most recent commit fixes the 302 license issue), and it's fetching the license correctly. I'd be interested in seeing what your experience is if you are willing to try? In any case, Hall is undergoing active development, and I'm hoping to have a fresh release end of this month, with a whole bunch of improvements and bug fixes. Definitely feel free to drop issues to me directly by email or on gitlab (though some of the ones you raised have been fixed, like the unknown filetype issue). Best wishes, Alex > Follow up question would be, how to bring the package into the guix > repository, but I am guessing, that it will be answered at > https://guix.gnu.org/cookbook/en/html_node/Direct-checkout-hacking.html, > which I have not read yet. > > Another question is, whether I should put you into the authors file and > write something like "help with packaging" there. What is the common > practice? > > Best regards, > Zelphir > > On 2/16/21 5:48 PM, Tim Van den Langenbergh wrote: >> Err, looking at your hall.scm file, you have the fslib file added to your >> libraries twice. >> >> Guix environment is not needed if you have all the requirements for building >> the package installed locally, but if you want to distribute your package it's >> good practise to ensure it builds in a clean environment (see also https:// >> guix.gnu.org/manual/en/html_node/Invoking-guix-environment.html for more >> information about Guix environments). >> >> The "COPYING" file is hardcoded as license file in Hall, to ensure compatibility >> with GNU standards: https://www.gnu.org/licenses/gpl-howto.en.html >> >> Hope this helps, >> >> Vale >> >> -Tim >> >> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 272 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: guile-hall issues converting my project to a hall project 2021-02-17 21:17 ` Alex Sassmannshausen @ 2021-02-18 19:16 ` Zelphir Kaltstahl 2021-02-21 13:42 ` Alex Sassmannshausen 0 siblings, 1 reply; 15+ messages in thread From: Zelphir Kaltstahl @ 2021-02-18 19:16 UTC (permalink / raw) To: alex.sassmannshausen; +Cc: guile-user Hi Alex! I am willing to test/try some more. When you say "since commit xyz", do you mean commit of guile-hall itself, or a commit of Guix, where an updated version of guile-hall is available? How would I test the master branch version? I would guess install it in a guix environment and then use that environment to try and convert a project. What would you suggest testing? It was quite OK to edit hall.scm in an editor. Perhaps, if a project is significantly bigger than my project, it would become cumbersome, but for me personally it is fine, now that I know what goes in there and how it needs to look. I have not yet begun writing a guide for converting a project. Hopefully I'll be able to do so soon. Best regards, Zelphir On 2/17/21 10:17 PM, Alex Sassmannshausen wrote: > Hi Zelphir and Tim, > > I am the author of guile hall — apologies for only now getting into this > thread. I'm afraid I have been somewhat distracted with other things. > > First of all I want to echo what others have said — thank you very much > for your detailed descriptions of what exactly happened when you tried > to migrate the project to guile hall. > > The aim of the project is to massively reduce the barrier of entry to > creating new, portable, high quality guile projects — and to contribute > them to Guix. Your descriptions suggest it's not there yet! > > In any case, some comments inline: > > Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes: > >> Hello Tim! >> >> Thank you, it works now! >> >> Removing the duplicate entry of `fslib` in hall.scm fixed it. > Fwiw, since commit ac76541a this issue can be automatically resolved by > running scan once more: it should remove duplicate entries in hall.scm. > >> Regarding the license: OK, I have no problem moving my license to >> `COPYING`. However, I still think, that it should not put GPL there, >> when I specified AGPL in `hall.scm`. This looks like a hardcoded >> fallback, which does not take the license specification into account. >> Something like: "If there is no `COPYING` file just put GPL into a file >> `COPYING`." instead of "If there is no `COPYING` file just put >> <user-specified-license-in-hall.scm> into a file `COPYING`.". I could be >> wrong though, as I do not know anything about guile-hall's internals. > This is odd — Hall should respect your license choice. It should, for > (A)GPL licenses automatically download those from the internet and > install them in COPYING. There was an issue with those licenses hiding > behind a 302 status code, which resulted in fallback text being loaded > in COPYING. But even that fallback text should respect your license. > > I just tried changing my license to AGPLv3+ in one of my projects, > running hall from Master (the most recent commit fixes the 302 license > issue), and it's fetching the license correctly. > > I'd be interested in seeing what your experience is if you are willing > to try? > > In any case, Hall is undergoing active development, and I'm hoping to > have a fresh release end of this month, with a whole bunch of > improvements and bug fixes. Definitely feel free to drop issues to me > directly by email or on gitlab (though some of the ones you raised have > been fixed, like the unknown filetype issue). > > Best wishes, > > Alex > >> Follow up question would be, how to bring the package into the guix >> repository, but I am guessing, that it will be answered at >> https://guix.gnu.org/cookbook/en/html_node/Direct-checkout-hacking.html, >> which I have not read yet. >> >> Another question is, whether I should put you into the authors file and >> write something like "help with packaging" there. What is the common >> practice? >> >> Best regards, >> Zelphir >> >> On 2/16/21 5:48 PM, Tim Van den Langenbergh wrote: >>> Err, looking at your hall.scm file, you have the fslib file added to your >>> libraries twice. >>> >>> Guix environment is not needed if you have all the requirements for building >>> the package installed locally, but if you want to distribute your package it's >>> good practise to ensure it builds in a clean environment (see also https:// >>> guix.gnu.org/manual/en/html_node/Invoking-guix-environment.html for more >>> information about Guix environments). >>> >>> The "COPYING" file is hardcoded as license file in Hall, to ensure compatibility >>> with GNU standards: https://www.gnu.org/licenses/gpl-howto.en.html >>> >>> Hope this helps, >>> >>> Vale >>> >>> -Tim >>> >>> -- repositories: https://notabug.org/ZelphirKaltstahl ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: guile-hall issues converting my project to a hall project 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 0 siblings, 1 reply; 15+ messages in thread From: Alex Sassmannshausen @ 2021-02-21 13:42 UTC (permalink / raw) To: Zelphir Kaltstahl; +Cc: guile-user [-- Attachment #1: Type: text/plain, Size: 5673 bytes --] Hi Zelphir, Some notes inline: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes: > I am willing to test/try some more. Great, that's really good to hear! > When you say "since commit xyz", do you mean commit of guile-hall > itself, or a commit of Guix, where an updated version of guile-hall is > available? I mean in the guile-hall repository. But you should be able to do: guix install guile-hall --with-commit="guile-hall=HASH" to get the right version. I *think* it should just build and work. > How would I test the master branch version? I would guess install it in > a guix environment and then use that environment to try and convert a > project. Yeah, that would work too. You should even be able to combine the two and go with: guix environment --ad-hoc guile guile-hall --with-commit="guile-hall=HASH" > What would you suggest testing? I think it would be best if you tried using the convert command and see whether it gets you better results this time around. Outside of that, probably playing with the new --skip option and `scan' arguments might be useful and interesting for you. > It was quite OK to edit hall.scm in an editor. Perhaps, if a project is > significantly bigger than my project, it would become cumbersome, but > for me personally it is fine, now that I know what goes in there and how > it needs to look. Good to hear. The spec was always meant to be human readable. Still, the new scan options might make it easier to add additional files gradually. > I have not yet begun writing a guide for converting a project. Hopefully > I'll be able to do so soon. That would be very interesting to see! Best wishes, Alex > > Best regards, > Zelphir > > On 2/17/21 10:17 PM, Alex Sassmannshausen wrote: >> Hi Zelphir and Tim, >> >> I am the author of guile hall — apologies for only now getting into this >> thread. I'm afraid I have been somewhat distracted with other things. >> >> First of all I want to echo what others have said — thank you very much >> for your detailed descriptions of what exactly happened when you tried >> to migrate the project to guile hall. >> >> The aim of the project is to massively reduce the barrier of entry to >> creating new, portable, high quality guile projects — and to contribute >> them to Guix. Your descriptions suggest it's not there yet! >> >> In any case, some comments inline: >> >> Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes: >> >>> Hello Tim! >>> >>> Thank you, it works now! >>> >>> Removing the duplicate entry of `fslib` in hall.scm fixed it. >> Fwiw, since commit ac76541a this issue can be automatically resolved by >> running scan once more: it should remove duplicate entries in hall.scm. >> >>> Regarding the license: OK, I have no problem moving my license to >>> `COPYING`. However, I still think, that it should not put GPL there, >>> when I specified AGPL in `hall.scm`. This looks like a hardcoded >>> fallback, which does not take the license specification into account. >>> Something like: "If there is no `COPYING` file just put GPL into a file >>> `COPYING`." instead of "If there is no `COPYING` file just put >>> <user-specified-license-in-hall.scm> into a file `COPYING`.". I could be >>> wrong though, as I do not know anything about guile-hall's internals. >> This is odd — Hall should respect your license choice. It should, for >> (A)GPL licenses automatically download those from the internet and >> install them in COPYING. There was an issue with those licenses hiding >> behind a 302 status code, which resulted in fallback text being loaded >> in COPYING. But even that fallback text should respect your license. >> >> I just tried changing my license to AGPLv3+ in one of my projects, >> running hall from Master (the most recent commit fixes the 302 license >> issue), and it's fetching the license correctly. >> >> I'd be interested in seeing what your experience is if you are willing >> to try? >> >> In any case, Hall is undergoing active development, and I'm hoping to >> have a fresh release end of this month, with a whole bunch of >> improvements and bug fixes. Definitely feel free to drop issues to me >> directly by email or on gitlab (though some of the ones you raised have >> been fixed, like the unknown filetype issue). >> >> Best wishes, >> >> Alex >> >>> Follow up question would be, how to bring the package into the guix >>> repository, but I am guessing, that it will be answered at >>> https://guix.gnu.org/cookbook/en/html_node/Direct-checkout-hacking.html, >>> which I have not read yet. >>> >>> Another question is, whether I should put you into the authors file and >>> write something like "help with packaging" there. What is the common >>> practice? >>> >>> Best regards, >>> Zelphir >>> >>> On 2/16/21 5:48 PM, Tim Van den Langenbergh wrote: >>>> Err, looking at your hall.scm file, you have the fslib file added to your >>>> libraries twice. >>>> >>>> Guix environment is not needed if you have all the requirements for building >>>> the package installed locally, but if you want to distribute your package it's >>>> good practise to ensure it builds in a clean environment (see also https:// >>>> guix.gnu.org/manual/en/html_node/Invoking-guix-environment.html for more >>>> information about Guix environments). >>>> >>>> The "COPYING" file is hardcoded as license file in Hall, to ensure compatibility >>>> with GNU standards: https://www.gnu.org/licenses/gpl-howto.en.html >>>> >>>> Hope this helps, >>>> >>>> Vale >>>> >>>> -Tim >>>> >>>> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 272 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* guile-hall packaging guide 2021-02-21 13:42 ` Alex Sassmannshausen @ 2021-02-22 11:34 ` Zelphir Kaltstahl 2021-02-22 20:52 ` Jérémy Korwin-Zmijowski 0 siblings, 1 reply; 15+ messages in thread From: Zelphir Kaltstahl @ 2021-02-22 11:34 UTC (permalink / raw) To: alex.sassmannshausen; +Cc: guile-user Hi Alex! I've begun writing the guide for using guile-hall to package GNU Guile libraries/programs: https://notabug.org/ZelphirKaltstahl/gnu-guile-gnu-guix-packaging-guide If you would like to take a look and if you see any mistakes, imprecise terminology, missing explanations or anything, please let me know and I will try to improve it. Still have to get to the tests with the master branch and all that. I guess I will first get a first version of that guide done and then use it to go through the steps testing the up-to-date version of guile-hall. Best regards, Zelphir On 2/21/21 2:42 PM, Alex Sassmannshausen wrote: > Hi Zelphir, > > Some notes inline: > > Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes: > >> I am willing to test/try some more. > Great, that's really good to hear! > >> When you say "since commit xyz", do you mean commit of guile-hall >> itself, or a commit of Guix, where an updated version of guile-hall is >> available? > I mean in the guile-hall repository. But you should be able to do: > guix install guile-hall --with-commit="guile-hall=HASH" > to get the right version. > > I *think* it should just build and work. > >> How would I test the master branch version? I would guess install it in >> a guix environment and then use that environment to try and convert a >> project. > Yeah, that would work too. > > You should even be able to combine the two and go with: > guix environment --ad-hoc guile guile-hall --with-commit="guile-hall=HASH" > >> What would you suggest testing? > I think it would be best if you tried using the convert command and see > whether it gets you better results this time around. Outside of that, > probably playing with the new --skip option and `scan' arguments might > be useful and interesting for you. > >> It was quite OK to edit hall.scm in an editor. Perhaps, if a project is >> significantly bigger than my project, it would become cumbersome, but >> for me personally it is fine, now that I know what goes in there and how >> it needs to look. > Good to hear. The spec was always meant to be human readable. Still, the > new scan options might make it easier to add additional files > gradually. > >> I have not yet begun writing a guide for converting a project. Hopefully >> I'll be able to do so soon. > That would be very interesting to see! > > Best wishes, > > Alex > >> Best regards, >> Zelphir >> >> On 2/17/21 10:17 PM, Alex Sassmannshausen wrote: >>> Hi Zelphir and Tim, >>> >>> I am the author of guile hall — apologies for only now getting into this >>> thread. I'm afraid I have been somewhat distracted with other things. >>> >>> First of all I want to echo what others have said — thank you very much >>> for your detailed descriptions of what exactly happened when you tried >>> to migrate the project to guile hall. >>> >>> The aim of the project is to massively reduce the barrier of entry to >>> creating new, portable, high quality guile projects — and to contribute >>> them to Guix. Your descriptions suggest it's not there yet! >>> >>> In any case, some comments inline: >>> >>> Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes: >>> >>>> Hello Tim! >>>> >>>> Thank you, it works now! >>>> >>>> Removing the duplicate entry of `fslib` in hall.scm fixed it. >>> Fwiw, since commit ac76541a this issue can be automatically resolved by >>> running scan once more: it should remove duplicate entries in hall.scm. >>> >>>> Regarding the license: OK, I have no problem moving my license to >>>> `COPYING`. However, I still think, that it should not put GPL there, >>>> when I specified AGPL in `hall.scm`. This looks like a hardcoded >>>> fallback, which does not take the license specification into account. >>>> Something like: "If there is no `COPYING` file just put GPL into a file >>>> `COPYING`." instead of "If there is no `COPYING` file just put >>>> <user-specified-license-in-hall.scm> into a file `COPYING`.". I could be >>>> wrong though, as I do not know anything about guile-hall's internals. >>> This is odd — Hall should respect your license choice. It should, for >>> (A)GPL licenses automatically download those from the internet and >>> install them in COPYING. There was an issue with those licenses hiding >>> behind a 302 status code, which resulted in fallback text being loaded >>> in COPYING. But even that fallback text should respect your license. >>> >>> I just tried changing my license to AGPLv3+ in one of my projects, >>> running hall from Master (the most recent commit fixes the 302 license >>> issue), and it's fetching the license correctly. >>> >>> I'd be interested in seeing what your experience is if you are willing >>> to try? >>> >>> In any case, Hall is undergoing active development, and I'm hoping to >>> have a fresh release end of this month, with a whole bunch of >>> improvements and bug fixes. Definitely feel free to drop issues to me >>> directly by email or on gitlab (though some of the ones you raised have >>> been fixed, like the unknown filetype issue). >>> >>> Best wishes, >>> >>> Alex >>> >>>> Follow up question would be, how to bring the package into the guix >>>> repository, but I am guessing, that it will be answered at >>>> https://guix.gnu.org/cookbook/en/html_node/Direct-checkout-hacking.html, >>>> which I have not read yet. >>>> >>>> Another question is, whether I should put you into the authors file and >>>> write something like "help with packaging" there. What is the common >>>> practice? >>>> >>>> Best regards, >>>> Zelphir >>>> >>>> On 2/16/21 5:48 PM, Tim Van den Langenbergh wrote: >>>>> Err, looking at your hall.scm file, you have the fslib file added to your >>>>> libraries twice. >>>>> >>>>> Guix environment is not needed if you have all the requirements for building >>>>> the package installed locally, but if you want to distribute your package it's >>>>> good practise to ensure it builds in a clean environment (see also https:// >>>>> guix.gnu.org/manual/en/html_node/Invoking-guix-environment.html for more >>>>> information about Guix environments). >>>>> >>>>> The "COPYING" file is hardcoded as license file in Hall, to ensure compatibility >>>>> with GNU standards: https://www.gnu.org/licenses/gpl-howto.en.html >>>>> >>>>> Hope this helps, >>>>> >>>>> Vale >>>>> >>>>> -Tim >>>>> >>>>> -- repositories: https://notabug.org/ZelphirKaltstahl ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: guile-hall packaging guide 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 0 siblings, 1 reply; 15+ messages in thread From: Jérémy Korwin-Zmijowski @ 2021-02-22 20:52 UTC (permalink / raw) To: Zelphir Kaltstahl, alex.sassmannshausen; +Cc: guile-user Le lundi 22 février 2021 à 12:34 +0100, Zelphir Kaltstahl a écrit : > I've begun writing the guide for using guile-hall to package GNU > Guile > libraries/programs: > > https://notabug.org/ZelphirKaltstahl/gnu-guile-gnu-guix-packaging-guide Wow, I have to read that ! Nice work ;-) Jérémy ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: guile-hall packaging guide 2021-02-22 20:52 ` Jérémy Korwin-Zmijowski @ 2021-02-23 16:32 ` Alex Sassmannshausen 0 siblings, 0 replies; 15+ messages in thread From: Alex Sassmannshausen @ 2021-02-23 16:32 UTC (permalink / raw) To: Jérémy Korwin-Zmijowski; +Cc: guile-user [-- Attachment #1: Type: text/plain, Size: 445 bytes --] seconded! Thanks for writing this, Zelphir! Alex Jérémy Korwin-Zmijowski <jeremy@korwin-zmijowski.fr> writes: > Le lundi 22 février 2021 à 12:34 +0100, Zelphir Kaltstahl a écrit : >> I've begun writing the guide for using guile-hall to package GNU >> Guile >> libraries/programs: >> >> https://notabug.org/ZelphirKaltstahl/gnu-guile-gnu-guix-packaging-guide > > Wow, I have to read that ! Nice work ;-) > > Jérémy [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 272 bytes --] ^ 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).