Il giorno dom, 06/02/2022 alle 21.34 +0000, Zelphir Kaltstahl ha scritto: > On 2/6/22 16:29, Vijay Marupudi wrote: > > Ognen Duzlevski <mak...@sdf.org> writes: > > > > > Have you tried Racket? If you haven't - try that and you will > > > find > > > recommending Guile to beginners to be much easier ;). On a > > > serious note, > > > there are other schemes that have their own package managers > > > (e.g. > > > Racket). > > I have, but I like Guile better, and want everyone to use it :) I > > think > > being an extension language is a very useful and important part of > > what > > makes Guile great. > > > > > IMHO, this learning curve is a part of learning any language. The > > > reason > > > why every language comes with a language "specific" manager is > > > because a > > > lot of people have tried to solve this problem and failed to find > > > the > > > magic bullet. At some level you are relying on the language's > > > portability itself, then on the same level you are wanting to > > > exploit > > > some of the language's specifics, then on the same level someone > > > comes > > > along and says for some packages this approach doesn't work... ;) > > I don't think it's fair to say that using packages in Guile just as > > easy/hard as other languages. Python / Javascript make this > > incredibly > > easy, and their ecosystem is evidence for that success. Their > > package > > managers have flaws, but they have benefits too, and those benefits > > would be great for Guile. > > > > Note that I'm not saying that this package manager has to do > > everything > > expected of a battle-tested production package manager. Just make > > it > > easier for beginners to use and make packages (which will be Guix > > compatible by default). And we should not underestimate what > > beginners > > can do for a language. They might be new to Guile, but possess a > > lot of > > other traits that would be great, like domain expertise in science, > > writing skills, etc. which would be great for the ecosystem. > > > > Advanced users can use Guix or do the ./configure && make && make > > install dance. > > I find using Guix to be much better than the ./configure && make && > make stuff. > The reason is, that I always think: "What, if it doesn't work and I > want to > clean up my system afterwards?". I can't stand it, if any remains of > non-working > stuff is left on the system. > > I am fine with using Guix. I like Guix. It is just that making a > package is way > to hard for newcomers. I needed weeks to make one simple pure Guile > package, > because I burned out trying to do it and had to have pauses in > between, before I > could muster new energy to try again. That still haunts me, so that I > still have > not updated my package, even though I have a newer release for months > by now. > Especially the whole (in the end unnecessary) autotools stuff was > exhausting. > Trying to understand what all those files do in my package. It is > sort of my own > problem, because I cannot leave it alone and just be done with it. I > want to > understand it.
Just don't That stuff is too low level for human beings The only autotools files you should care about are the ones meant to be written by a human being (the package author) The ones it produces in its own are not meant to be "understood" With Guile-Hall you don't even need to understand the autotools files meant to be edited by human beings Becaue Hall will edit those for you BUT The essential part is short and it's as follows There are 2 people in ths scenario: you (the package author) and someone who downloads your package and runs configure; make The autoconf file you (the package author) edit is meant to produce a bash script Such bash file is called "configure" (it will be called by the user of your package) and it does 2 things: 1) checks features available on the system of the user running configure; make 2) based on the results of the checks (and also based on another file), writes a makefile that will pilot the building So now you can call make and make will execute the makefile written previously That's all Now: Guix leverages this machinery to manage your package Because of that, defining an autotools based package for Guix is easier than it is to configure a package that has no build system because if your package has no build system, the building process will have to be expressed in Guix code If, instead, it has a build system (the autotools or any other) Guix will charge the build system with the building process, maybe calling its APIs, so the definition can be more streamlined Anyway, I feel your frustration, I've been there myself Actually I've been there with Guile more than with Guix But still I feel you I hope this message of mine can sooth your frustration, to some extent
