unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
To: James Crake-Merani <james@jamescm.co.uk>
Cc: guile-user@gnu.org
Subject: Re: Scripting for installing a module
Date: Sun,  3 Jul 2022 16:52:42 +0000	[thread overview]
Message-ID: <3395a4b7-348a-fcee-64d2-f3e888aa9151@posteo.de> (raw)
In-Reply-To: <20220703073529.mcirf2tyhhwmmhmk@arch-surface>


On 7/3/22 09:35, James Crake-Merani wrote:
> On 22/07/02 07:43pm, Zelphir Kaltstahl wrote:
>> On 7/2/22 10:46, James Crake-Merani wrote:
>>> On 22/07/02 09:11am, adriano wrote:
>>>> Il giorno ven, 01/07/2022 alle 18.15 +0100, James Crake-Merani ha
>>>> scritto:
>>>>> Hello,
>>>>>
>>>>> I was just wondering what approach people tend to take when writing a
>>>>> script which installs a module onto the load-path. I understand this
>>>>> path might be different on different machines so how do you make sure
>>>>> the module is installed in the right path? Would you use something
>>>>> like a Makefile?
>>>> not only a Makefile
>>>>
>>>> The whole Autotools chain
>>>>
>>>> There are 2 options:
>>>>
>>>> 1) you write the config.am and Makefile.am (or however they're called)
>>>> by hand and you deal with the Autotools directly, by hand
>>>>
>>>> 2) You use guile-hall and it will wrap the Autotools making the
>>>> experience a bit less frustrating
>>>>
>>>>
>>>>
>>>> BUT
>>>>
>>>> I wonder: why you want to install your module ?
>>>>
>>>> You might want to distribute it as a simple handful of source files
>>>>
>>>> Guile will compile it automagically at need
>>>>
>>>> If your module has no dependencies, that could be an easy option
>>>>
>>>> If it _has_ dependencies, then the Autotools might be of help
>>>>
>>>> Did you think about this ?
>>>>
>>>> I hate to second guess your question
>>>>
>>>> I understand it might be perceived as rude and I'm sorry for that
>>>>
>>>> I just think these distinctions in use cases are not clear at all, in
>>>> the manual and in general
>>>>
>>>> So this could be an easy pitfall
>>> Hi,
>>>
>>> Don't worry, you didn't come across as rude at all. My use case was simply that I wrote some modules that I wanted to distribute, and I thought that if I'm going to distribute them, I probably ought to put some sort of script in so users can install them as well. The modules in question are just a simple project which tests your conformance to a certain political ideology (which is not sophisticated at all because it was more of a joke between friends that I thought would make a good programming exercise). After seeing Guile Hall recommended by yourself, and Jeremy I thought this might be appropriate. My modules have no dependencies aside from those already part of Guile although I do intend to write another module which will depend on the previous module.
>>>
>>> So if I were to take the latter approach of just distributing the source code then I presume users would have to load the file manually, or install it manually unless I'm missing something. In that case, I would've thought using something like Guile Hall would be more appropriate but again I might be missing something.
>>>
>>> I have just found the manual pages detailing Guile Hall which I was not originally aware of. After reading them, it does seem to me that Hall would be appropriate for this but of course I would be willing to hear about alternatives to distributing the code.
>>>
>>> Thanks for your response.
>> Hello James!
>>
>> If your code is Guile code exclusively, then you might not need Guile Hall
>> for packaging your code. You can make a GNU Guix package without Guile Hall.
>> That is not to say, that Guile Hall does not work well, but I had a project,
>> which I wanted to package and ultimately I did not want to depend on all the
>> autotools machinery, which I do not understand. It has been a while, since I
>> have packaged anything (I should really clean the repo a bit …), but the
>> project I have is https://notabug.org/ZelphirKaltstahl/guile-fslib. I think
>> tag 0.2.1 should contain a valid guix.scm. This repo also still has files
>> from previous Guile Hall attempts. However, you might have to study the docs
>> to get things working for your own project and how to test it with guix. I
>> remember, that I used a VM for testing installation of the package.
>> Somewhere I have a repository, which describes the process.
>>
>> Regards,
>> Zelphir
>>
>> -- 
>> repositories: https://notabug.org/ZelphirKaltstahl
>>
> Hi,
>
> The reason why I have been a bit reluctant to use GNU Guix for this sort of thing is that the distro I use is not Guix but rather Arch Linux. I do intend to try out GNU Guix in the future but at the moment I have lots of other things to do. I am aware Guix does work on foreign distros but I will need to learn how to use it first.
>
> I understand what you say regarding Guile Hall. I too do not understand the autotools machinery but it did seem simple to setup without that understanding. Thanks for sharing your repository.
>
> I think for now I will probably end up using Guile Hall although I might experiment with just purely Guix, and see if I can get that to work how I want it as well.
>
> Thanks.

Hi James!

You might already know this, but just in case you don't: You can also use Guix 
package manager without running the Guix distribution. This is called "Guix on 
foreign distro". For me this works well. If you already knew, nevermind : )

Regards,
Zelphir

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




  reply	other threads:[~2022-07-03 16:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-01 17:15 Scripting for installing a module James Crake-Merani
2022-07-01 19:50 ` Jérémy Korwin-Zmijowski
2022-07-02  6:32   ` James Crake-Merani
2022-07-02  7:11 ` adriano
2022-07-02  8:46   ` James Crake-Merani
2022-07-02 19:43     ` Zelphir Kaltstahl
2022-07-03  7:35       ` James Crake-Merani
2022-07-03 16:52         ` Zelphir Kaltstahl [this message]
2022-07-05  8:14         ` Munyoki Kilyungi
2022-07-05  9:46           ` James Crake-Merani
2022-07-02 21:09 ` Matt Wette
2022-07-03  7:37   ` james

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3395a4b7-348a-fcee-64d2-f3e888aa9151@posteo.de \
    --to=zelphirkaltstahl@posteo.de \
    --cc=guile-user@gnu.org \
    --cc=james@jamescm.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).