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
