guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to make GNU Guile more successful


From: vbuaraujo
Subject: Re: How to make GNU Guile more successful
Date: Fri, 10 Mar 2017 14:27:35 +0000
User-agent: IMP PTMail 5.12.21

Citando Panicz Maciej Godek <address@hidden>:

2017-03-10 10:55 GMT+01:00 Arne Babenhauserheide <address@hidden>:


Vítor De Araújo writes:

> (Or maybe package _names_ could be URLs pointing to an index in a
> well-defined format, which tells how to download each version of a
> package; then we could have even dependency management without a
> central repository. I'm pipe-dreaming here, though.)

You’re not just dreaming:

https://github.com/plande/compan/blob/master/compan.scm

    ;; clone the repository and load (lib) module from the top level:
    (load-modules ("https://bitbucket.org/panicz/dogma"; (lib)))

    ;; as above, but load modules from "libraries" directory:
    (load-modules (("https://github.com/panicz/pamphlet"; "libraries")
(pamphlet)))

    ;; one can also fix on a particular tag/branch/commit:
    (load-modules (("https://bitbucket.org/panicz/dogma"; "."
"3884445191c2") (lib)))

We’d just have to decide to use this.

That's very cool :) And also supports my point that there should be something
like a wiki for publishing information about Guile packages. It'd be hard
for me to find this on my own.

I think that the situation isn't quite as good as one could think. The
code works fine from
the interpreter, but if fails to work for compiled code, and I think that
we'd need to come up
with some solution of delaing module imports in compiled code until they're
available.

(Note also that the source code of Compan is extremely straightforward, as
it boils down
to a few calls of the "system" function which in turns calls some "hg"
commands)

So while I think that the author's idea was very nice, it clearly needs
some elaboration :)

Yeah, for one I don't think the URLs should go directly into the code, but
rather in a package metadata file. The reason is I don't think we should
hard-code the package manager in the code. People should be able to use
the code without having the package manager, if they already have the
dependencies installed by some other means. But the basic idea is cool. :)

--
Vítor De Araújo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]