a blog post

[Catonano]

Hello fellow guixers,

I posted a brand new post in my little personal somewhat indie blog

It's about Guix, Guile and Free Software in general. From my very own point
of view

You can find it here
http://catonano.v22018025836661967.nicesrv.de/guile-and-free-software.html

There's also a feed, reachable here
http://catonano.v22018025836661967.nicesrv.de/feed.xml

I hope you're not bothered by this shamelessly self promotional post on the
mailing list

But I remember Ludo saying that not only new packages and services would be
needed for the future of Guix but also community oriented stuff such as
blog posts and maybe screencasts and so on

The blog is made with Haunt and it's completely Javascript free. This
should make the consultation easier from Tor

Too bad I couldn't take care of the fonts yet so it still points to some
Google provided fonts 😓

Also, I host it on a vps by netcup.de, a German provider, I don't know how
that fares with Tor either.
I hope not too bad

So, this is it
Thanks

[Pjotr Prins]

Hi Catano,

Thanks for the blog.

Indeed, I love working with Guix and developing with Guix. Guix takes
care of my deployment and configuration requirements.

I have written some time in the past that with Guix you don't need
autotools. The main thing autotools solve is configuring the build for
an environment. At the same time, with Guix you get a predictable
environment, so a make file (or similar) suffices. It is what I do in
all my development projects - I don't use autotools to develop and
deploy them. It greatly simplifies my existence :). Indeed, I have
never liked autotools (essentially a nasty hack) and only used them
before Nix/Guix. So, my approach is the same as yours :)

You can do without autotools once inside Guix and once you decide to
ignore targeting other distributions. Which I do, though I have ways
of deploying Guix built packages on other systems without Guix which
people also use. E.g.

https://github.com/genetics-statistics/GEMMA/releases

The top files include a binary Guix package installer. You can try it.
It is a way of distributing pre-built code on other systems. If you
are interested you could package your stuff too. Though it probably
makes less sense for a library for Guile until it becomes something
accepted by the Guile ecosystem.

Pj.

[Ludovic Courtès]

Hello!

Post by Pjotr Prins
Indeed, I love working with Guix and developing with Guix. Guix takes
care of my deployment and configuration requirements.
I have written some time in the past that with Guix you don't need
autotools. The main thing autotools solve is configuring the build for
an environment. At the same time, with Guix you get a predictable
environment, so a make file (or similar) suffices. It is what I do in
all my development projects - I don't use autotools to develop and
deploy them. It greatly simplifies my existence :). Indeed, I have
never liked autotools (essentially a nasty hack) and only used them
before Nix/Guix. So, my approach is the same as yours :)

+1!

If we could provide tooling with an abstraction level close to that of a
makefile, that’d help a lot.

Actually, just like we have ‘emacs-build-system’, we could very much add
‘guile-build-system’ for simple Guile packages that don’t need/use
Autoconf & co.

‘guile-build-system’ would automatically run ‘guild compile’,
‘makeinfo’, etc. pretty much like we do here:

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/guile.scm#n870

Once we have that, developers of Guile packages can simply drop a
‘.guix’ file in their project and use it with ‘guix environment’, ‘guix
build’, and ‘guix package’.

That’s coarser-grain than a makefile, of course, but would be a good
first step to providing tooling for people working on Guile code.

Any takers for ‘guile-build-system’?


A next step could be to add a tool that understands a syntax like that
of the guildhall, which gets us closer to the makefile/Makefile.am level
of abstraction:

https://github.com/ijp/guildhall/blob/master/docs/packaging.texi#L121

Ludo’.

[julien lepiller]

Post by Ludovic Courtès
Hello!

Post by Pjotr Prins
Indeed, I love working with Guix and developing with Guix. Guix takes
care of my deployment and configuration requirements.
I have written some time in the past that with Guix you don't need
autotools. The main thing autotools solve is configuring the build for
an environment. At the same time, with Guix you get a predictable
environment, so a make file (or similar) suffices. It is what I do in
all my development projects - I don't use autotools to develop and
deploy them. It greatly simplifies my existence :). Indeed, I have
never liked autotools (essentially a nasty hack) and only used them
before Nix/Guix. So, my approach is the same as yours :)

+1!
If we could provide tooling with an abstraction level close to that of a
makefile, that’d help a lot.

I don't really agree mixing a package manager and a build tool is a
good idea. Sure, it helps a lot because they both solve the same kind
of problem and I certainly see what advantage it would have, but so do
maven devs. They mixed a package manager and a build system together.
It became the official way to build many packages, including its own
dependencies. As a result, it became a total mess to build maven from
scratch. So if someone wants to build a package whose only build
system is guix but can't use guix for some reason (maybe it wasn't
ported to their platform?) will just cry and hate us.

Post by Ludovic Courtès
Actually, just like we have ‘emacs-build-system’, we could very much add
‘guile-build-system’ for simple Guile packages that don’t need/use
Autoconf & co.

That's more reasonable though :)

Post by Ludovic Courtès
‘guile-build-system’ would automatically run ‘guild compile’,
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/guile.scm#n870
Once we have that, developers of Guile packages can simply drop a
‘.guix’ file in their project and use it with ‘guix environment’, ‘guix
build’, and ‘guix package’.
That’s coarser-grain than a makefile, of course, but would be a good
first step to providing tooling for people working on Guile code.
Any takers for ‘guile-build-system’?
A next step could be to add a tool that understands a syntax like that
of the guildhall, which gets us closer to the makefile/Makefile.am level
https://github.com/ijp/guildhall/blob/master/docs/packaging.texi#L121
Ludo’.

[Catonano]

Post by Ludovic Courtès
Hello!

Post by Pjotr Prins
Indeed, I love working with Guix and developing with Guix. Guix takes
care of my deployment and configuration requirements.
I have written some time in the past that with Guix you don't need
autotools. The main thing autotools solve is configuring the build for
an environment. At the same time, with Guix you get a predictable
environment, so a make file (or similar) suffices. It is what I do in
all my development projects - I don't use autotools to develop and
deploy them. It greatly simplifies my existence :). Indeed, I have
never liked autotools (essentially a nasty hack) and only used them
before Nix/Guix. So, my approach is the same as yours :)

+1!
If we could provide tooling with an abstraction level close to that of a
makefile, that’d help a lot.
Actually, just like we have ‘emacs-build-system’, we could very much add
‘guile-build-system’ for simple Guile packages that don’t need/use
Autoconf & co.
‘guile-build-system’ would automatically run ‘guild compile’,
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/
packages/guile.scm#n870
Once we have that, developers of Guile packages can simply drop a
‘.guix’ file in their project and use it with ‘guix environment’, ‘guix
build’, and ‘guix package’.
That’s coarser-grain than a makefile, of course, but would be a good
first step to providing tooling for people working on Guile code.
Any takers for ‘guile-build-system’?

Ahem... that would be me

This would be the most advanced thing I' ve ever done in Guile until now

Recently rekado observed that (system*... does NOT spawn a shell and
execute commands in it

That was a surprise for me

Also in the Guile manual I found getcwd and a "chdir" (or something) in
order to run a Unix command from within a certain folder

So I feel less in the dark than I felt until a short time ago

And anyway, I' ll pester you, should I get stuck

I won' t be fast, but I' ll keep you updated ;-)

Post by Ludovic Courtès
A next step could be to add a tool that understands a syntax like that
of the guildhall, which gets us closer to the makefile/Makefile.am level
https://github.com/ijp/guildhall/blob/master/docs/packaging.texi#L121

it's early for this one

We' ll see

[Christopher Lemmer Webber]

Post by Ludovic Courtès
Hello!

Post by Pjotr Prins
Indeed, I love working with Guix and developing with Guix. Guix takes
care of my deployment and configuration requirements.
I have written some time in the past that with Guix you don't need
autotools. The main thing autotools solve is configuring the build for
an environment. At the same time, with Guix you get a predictable
environment, so a make file (or similar) suffices. It is what I do in
all my development projects - I don't use autotools to develop and
deploy them. It greatly simplifies my existence :). Indeed, I have
never liked autotools (essentially a nasty hack) and only used them
before Nix/Guix. So, my approach is the same as yours :)

+1!
If we could provide tooling with an abstraction level close to that of a
makefile, that’d help a lot.
Actually, just like we have ‘emacs-build-system’, we could very much add
‘guile-build-system’ for simple Guile packages that don’t need/use
Autoconf & co.
‘guile-build-system’ would automatically run ‘guild compile’,
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/guile.scm#n870
Once we have that, developers of Guile packages can simply drop a
‘.guix’ file in their project and use it with ‘guix environment’, ‘guix
build’, and ‘guix package’.
That’s coarser-grain than a makefile, of course, but would be a good
first step to providing tooling for people working on Guile code.
Any takers for ‘guile-build-system’?
A next step could be to add a tool that understands a syntax like that
of the guildhall, which gets us closer to the makefile/Makefile.am level
https://github.com/ijp/guildhall/blob/master/docs/packaging.texi#L121
Ludo’.

While this is a fun idea, I'd still much rather have a guile-based
DSL replacement for autotools type things that's standalone (but maybe
also which can export to shell if need be).

David Thompson has made many comments before on the mistake of mixing
build systems and package managers... I'm a bit worried that we might be
encouraging going down that same path?

[Chris Marusich]

Post by Christopher Lemmer Webber
David Thompson has made many comments before on the mistake of mixing
build systems and package managers... I'm a bit worried that we might be
encouraging going down that same path?

The Guix daemon implements the functional software deployment model.
That model can, in theory, be used to create various things. One of
those things is a package manager. Another of those things is a
continuous integration server farm (e.g., Hydra, Cuirass). Another of
those things is a make-like build system (not yet created).

A make-like build system that leverages the functional software
deployment model by using the Guix daemon can, in theory, remain largely
decoupled from Guix, which is a package manager that happens to also
leverage the functional software deployment model by using the Guix
daemon. This is similar to how, in theory, you could run Nix alongside
Guix and have them both use the same daemon.

So, I don't think the notion of creating a build system that leverages
the functional software deployment model by using the Guix daemon is
unreasonable. However, I do agree it would be smart to think about ways
to keep such a build system decoupled from Guix, the package manager.

[Ludovic Courtès]

Hi Chris & Chris, :-)

Post by Chris Marusich

Post by Christopher Lemmer Webber
David Thompson has made many comments before on the mistake of mixing
build systems and package managers... I'm a bit worried that we might be
encouraging going down that same path?

The Guix daemon implements the functional software deployment model.
That model can, in theory, be used to create various things. One of
those things is a package manager. Another of those things is a
continuous integration server farm (e.g., Hydra, Cuirass). Another of
those things is a make-like build system (not yet created).

Exactly, that was the spirit of my suggestion.

Now I’d be interested in reading David’s arguments!

Ludo’.

[Ludovic Courtès]

Hello,

Post by Christopher Lemmer Webber
While this is a fun idea, I'd still much rather have a guile-based
DSL replacement for autotools type things that's standalone (but maybe
also which can export to shell if need be).

Yeah, not depending on Guix would have pros (it’d be more widely
applicable), and cons (limited world view).

Food for thought!

Ludo’.

[Catonano]

Post by Ludovic Courtès
Hello,

Post by Christopher Lemmer Webber
While this is a fun idea, I'd still much rather have a guile-based
DSL replacement for autotools type things that's standalone (but maybe
also which can export to shell if need be).

Yeah, not depending on Guix would have pros (it’d be more widely
applicable), and cons (limited world view).
Food for thought!
Ludo’.

there' s this file guix/buid/emacs-utils.scm

it contains utilities to let Emacs byte-compile elisp files

So that' s an Emacs build system and it' s embedded in Guix

My initial idea was to do something similar with Guile

But then I tought that it could have been a stand alone package

Today in the morning I could manage to take a look at this issue

I made a script that visits the file system tree of a project and compiles
the .scm files

Here' s a short demo

It doesn' t check the availability of dependencies (other guile packages)
yet

I was not sure how to achieve that

I saw that Automake generates snippets of bash scripting that try to run
guile with an expression loading the required module and if that fails then
the module is not available

The same functionality could be reproduced in Guile

I also saw the guildhall files that Ludo mentioned

So the thing is that the interface towards the user should be like those
guildhall files

and the interface towards the system should be like the Automake one

But, like Automake, it should only check if a Guile module is reachable on
the guile load path

If it' s not it shouldn't try manouvres: no sat solving, no fetching,
nothing.

A dependency could be there because you installed it with apt-get or with
dnf or because you used configure make on a manually downloaded guile
package

Or because you installed it with Guix or Nix

If it' s there, fine. if it' s not, that' s bad, the package can' t be built

What I mean is that this should be a build system, not a package management
system

This should address the concern that has been raised

Does it ?

I'll publish this soon, reviews and contributions appreciated ☺

[Catonano]

Post by Catonano

Post by Ludovic Courtès
Hello,

Post by Christopher Lemmer Webber
While this is a fun idea, I'd still much rather have a guile-based
DSL replacement for autotools type things that's standalone (but maybe
also which can export to shell if need be).

Yeah, not depending on Guix would have pros (it’d be more widely
applicable), and cons (limited world view).
Food for thought!
Ludo’.

there' s this file guix/buid/emacs-utils.scm
it contains utilities to let Emacs byte-compile elisp files
So that' s an Emacs build system and it' s embedded in Guix
My initial idea was to do something similar with Guile
But then I tought that it could have been a stand alone package
Today in the morning I could manage to take a look at this issue
I made a script that visits the file system tree of a project and compiles
the .scm files
Here' s a short demo
http://youtu.be/LaypeR8uw3Q
It doesn' t check the availability of dependencies (other guile packages)
yet
I was not sure how to achieve that
I saw that Automake generates snippets of bash scripting that try to run
guile with an expression loading the required module and if that fails then
the module is not available
The same functionality could be reproduced in Guile
I also saw the guildhall files that Ludo mentioned
So the thing is that the interface towards the user should be like those
guildhall files
and the interface towards the system should be like the Automake one
But, like Automake, it should only check if a Guile module is reachable on
the guile load path

I am experimenting with this line

(system* "guile" "-c" "(use-modules (commonmark)) (exit ((lambda () 0)))")

If it finds the module it returns 0

Otherwise it returns a different number

I copied some bits for a configure script for a Guile project instrumented
with the Autotools

I could use an example of usage of "status:Exit-val"

The Guile manual says:

Return the exit status value, as would be set if a process ended
normally through a call to ‘exit’ or ‘_exit’, if any, otherwise
‘#f’.

this is not enouhg for me to understand

In which scenario is thhis function supposed to be used ? In order to do
what ?
An example would be of great help

Anyway: Is this the idiomatic way ?

Or maybe I should use some try catch form wrapping some module loading
instruction ?
Without launching a different guile process ?

Thanks for any hint

[Catonano]

Post by Catonano

Post by Catonano

Post by Ludovic Courtès
Hello,

Post by Christopher Lemmer Webber
While this is a fun idea, I'd still much rather have a guile-based
DSL replacement for autotools type things that's standalone (but maybe
also which can export to shell if need be).

Yeah, not depending on Guix would have pros (it’d be more widely
applicable), and cons (limited world view).
Food for thought!
Ludo’.

there' s this file guix/buid/emacs-utils.scm
it contains utilities to let Emacs byte-compile elisp files
So that' s an Emacs build system and it' s embedded in Guix
My initial idea was to do something similar with Guile
But then I tought that it could have been a stand alone package
Today in the morning I could manage to take a look at this issue
I made a script that visits the file system tree of a project and
compiles the .scm files
Here' s a short demo
http://youtu.be/LaypeR8uw3Q
It doesn' t check the availability of dependencies (other guile packages)
yet
I was not sure how to achieve that
I saw that Automake generates snippets of bash scripting that try to run
guile with an expression loading the required module and if that fails then
the module is not available
The same functionality could be reproduced in Guile
I also saw the guildhall files that Ludo mentioned
So the thing is that the interface towards the user should be like those
guildhall files
and the interface towards the system should be like the Automake one
But, like Automake, it should only check if a Guile module is reachable
on the guile load path

I am experimenting with this line
(system* "guile" "-c" "(use-modules (commonmark)) (exit ((lambda () 0)))")
If it finds the module it returns 0
Otherwise it returns a different number
I copied some bits for a configure script for a Guile project instrumented
with the Autotools
I could use an example of usage of "status:Exit-val"
Return the exit status value, as would be set if a process ended
normally through a call to ‘exit’ or ‘_exit’, if any, otherwise
‘#f’.
this is not enouhg for me to understand
In which scenario is thhis function supposed to be used ? In order to do
what ?
An example would be of great help
Anyway: Is this the idiomatic way ?
Or maybe I should use some try catch form wrapping some module loading
instruction ?
Without launching a different guile process ?
Thanks for any hint

so

this line (notice the module is named commonmarL)

(system* "guile" "-c" "(use-modules (commonmarl)) (exit ((lambda () 0)))")

returns 256

while this one

(status:exit-val (system* "guile" "-c" "(use-modules (commonmarl)) (exit
((lambda () 0)))"))

returns 1

what's the point ?

[Ludovic Courtès]

Hi Catonano,

That’s a lot of text :-) and it seems we’ve drifted away from the
initial discussion.

Perhaps this should go to guile-***@gnu.org, or did I mischaracterize
what you were asking?

Thanks,
Ludo’.

[Ricardo Wurmus]

Hi Catonano,

Post by Catonano
I am experimenting with this line
(system* "guile" "-c" "(use-modules (commonmark)) (exit ((lambda () 0)))")
If it finds the module it returns 0
Otherwise it returns a different number
I copied some bits for a configure script for a Guile project instrumented
with the Autotools
I could use an example of usage of "status:Exit-val"
Return the exit status value, as would be set if a process ended
normally through a call to ‘exit’ or ‘_exit’, if any, otherwise
‘#f’.
this is not enouhg for me to understand
In which scenario is thhis function supposed to be used ? In order to do
what ?
An example would be of great help

With this procedure you can obtain the return status for “system*”.
Here’s an example:

--8<---------------cut here---------------start------------->8---
(display "Checking for commonmarl...")
(let ((status
(parameterize ((current-error-port (%make-void-port "w")))
(status:exit-val (system* "guile" "-c"
"(begin (use-modules (commonmarl))
(exit 0))")))))
(display (if (zero? status)
"Success!"
"Oh no!"))
(newline))
--8<---------------cut here---------------end--------------->8---

Post by Catonano
Anyway: Is this the idiomatic way ?
Or maybe I should use some try catch form wrapping some module loading
instruction ?
Without launching a different guile process ?

There are advantages to spawning a new guile process. One is that
whatever modules you may have loaded for your tool won’t affect the
check. It’s possible that your tool bundles a bunch of modules, but
when Guile is spawned in a pure environment it won’t be able to load
these modules. You may want to fail the configure test then.

On the other hand, it’s ugly to pass a Guile programme as a string to
system*, when you could do that instead with pure Guile. I haven’t
thought enough about this to give a recommendation either way.

--
Ricardo

[Erik Edrosa]

Hello Catonano,

Thanks for the blog post, I added your feed to my feed reader. I
understand your frustration with autotools, it can be difficult to
figure out how to get autotools to do what you want. The benefit of
autotools is that it creates the same interface to build, test, and
install GNU software (of course if implemented the correctly...). This
interface usually makes it easier for others to package for their
distribution.

What I think we need to do to improve Guile's chances for success is to
take a serious look at our tools and practices, improve them if needed,
and document the best ways to set up Guile and use it. Guix is great,
but we can't forget Guile users who don't use Guix. This probably
includes packaging Guile libraries for these other package managers.

- Erik (OrangeShark)

[Hartmut Goebel]

Post by Catonano
It's about Guix, Guile and Free Software in general. From my very own
point of view

Quote:

[org.mode…] as far as I understand some Google employees worked on it.

Does one become blessed and enlightened by getting employed by Gugle? Is
Gugle a magic guild?

Sorry, can't stand this google devoutness.

[Tobias Geerinckx-Rice]

Post by Hartmut Goebel

Post by Catonano
It's about Guix, Guile and Free Software in general. From my very own
point of view

[org.mode…] as far as I understand some Google employees worked on it.
Does one become blessed and enlightened by getting employed by Gugle? Is
Gugle a magic guild?

Who knows? Who cares?

I wonder why you think this an appropriate reply to a blog post that
clearly implies neither, and how it will influence people still
considering writing about Guix.

Kind regards,

T G-R

Sent from a Web browser. Excuse or enjoy my brevity.

[Catonano]

Post by Catonano
It's about Guix, Guile and Free Software in general. From my very own
point of view

[org.mode
] as far as I understand some Google employees worked on it.
Does one become blessed and enlightened by getting employed by Gugle? Is
Gugle a magic guild?
Sorry, can't stand this google devoutness.

Hartmut,

it's not devoutness

What I was trying to convey is that org-mode reached a wide community, it
entered places where the common attitude towards the gpl is of prudence, to
say at least.

I was not referring to a technological success but rather to a
communitarian (political ?) one.

Guile is light years far away from such a success, sadly.

That said, I also expect the average Google engineer to be quite competent.
But admittedly that's not by direct experience

That's all ☺

[Chris Marusich]

Post by Catonano
I posted a brand new post in my little personal somewhat indie blog

Thank you for sharing it!

Post by Catonano
I remember Ludo saying that not only new packages and services would
be needed for the future of Guix but also community oriented stuff
such as blog posts and maybe screencasts and so on

Yes. Even if a piece of software is the best software in the world,
it's unlikely to gain mind-share unless people try using it and talk
about it.

Post by Catonano
I host it on a vps by netcup.de, a German provider, I don't know how
that fares with Tor either. I hope not too bad

It worked for me just fine!