[Top][All Lists]

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

Re: How to make GNU Guile more successful

From: Vítor De Araújo
Subject: Re: How to make GNU Guile more successful
Date: Sat, 11 Mar 2017 00:02:09 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.8.0

On 10/03/2017 21:50, Vítor De Araújo wrote:
> I thought a little bit about the packages-as-urls idea and I had some
> ideas I'll just throw out here.
> First, I realized using the URL as the package _name_ is problematic,
> because it hard-codes the source of the package; that complicates things
> if someone wants to make a fork of the package and install it in place
> of the original. However, packages can still have a normal name and a
> "canonical URL" for fetching it.
> The package would come with a metadata file (named something like
> metadata.foopkg, where 'foopkg' is a placeholder for the name of the
> package manager (and I'd rather have the name of the package manager as
> an extension, because I'd rather not assume I'm the only package manager
> in the world)). This metadata would contain the package name, version,
> and dependencies. For each dependency, it would specify the package
> name, the version, *and the canonical URL* for that package. Upoin
> installation, the package manager would go through each dependency and
> check if a package of that name and compatible version (assuming
> semantic versioning) is already installed; if it's not, it would fetch
> it from the canonical URL.
> In this way, we can have decentralized package management which can
> handle dependencies.

Just one more little thought on package names vs. URLs. Guile already
has a standard module system, and modules already have names which are
supposed to be globally unique, and even they even have version numbers.
So module names can double as package names. The advantage is that then
you can check whether a dependency is installed *whether or not it was
installed via the package manager*. Basically you'd describe your
dependencies in terms of modules, and specify where the package that
implements that module can be fetched from.

I have to think this through a bit more, though.

Vítor De Araújo

reply via email to

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