[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
- Re: How to make GNU Guile more successful, (continued)
Re: How to make GNU Guile more successful, Amirouche, 2017/03/10
- Yet another GNU Guile package manager (Fwd: Re: How to make GNU Guile more successful), Amirouche, 2017/03/10
- Re: Yet another GNU Guile package manager (Fwd: Re: How to make GNU Guile more successful), Nala Ginrut, 2017/03/10
- Re: Yet another GNU Guile package manager (Fwd: Re: How to make GNU Guile more successful), Amirouche, 2017/03/11
- Re: Yet another GNU Guile package manager (Fwd: Re: How to make GNU Guile more successful), carl hansen, 2017/03/16
- Re: Yet another GNU Guile package manager (Fwd: Re: How to make GNU Guile more successful), Matt Wette, 2017/03/16
- Re: Yet another GNU Guile package manager (Fwd: Re: How to make GNU Guile more successful), Alex Kost, 2017/03/16
Re: How to make GNU Guile more successful, Vítor De Araújo, 2017/03/10
Re: How to make GNU Guile more successful,
Vítor De Araújo <=
Re: How to make GNU Guile more successful, Thien-Thi Nguyen, 2017/03/11
Re: How to make GNU Guile more successful, Christopher Allan Webber, 2017/03/13