Contributing libraries

[abaljeu]

@jan

My original hope was that the packs would in part act as a playing field for stuff to be added to the main system. That didn’t really happen. The packs do influence the core system though. Consider e.g., arouter that influenced the http_dispatch library, sort_dict that gave rise to support dict sorting in the ECLiPSe derived sort/4, etc. One of the reasons is that many of the packs build on each other, creating a parallel universe that often duplicates significant parts of the core functionality. I typically do not want to copy that as I want to avoid that the core contains too many libraries that do more or less the same but a little differently.

Following on everything else that’s been said, might we get down to business and address this insight? It seems we want these packs to use core functionality, and if they don’t because of gaps in the core, is that something that can be filled using code extracted from these packs?

[peter.ludemann]

@jan

User packs can be upgraded using ?- pack_upgrade(Pack).

That requires me remembering what all my packs are and remembering to upgrade them (and, because a pack can be imported with use_module(library(Pack)), it’s not even obvious from looking at the code that it is a pack and not core). A simpler upgrade mechanism would be nice.
(Python’s “pip” has a similar problem, which apparently hasn’t been solved yet.)

[abaljeu]

use_module(library(Pack))? I would have voted to require use_module(pack(Pack)).

[jan]

use_module(library(Pack)) was indeed probably too ambiguous. A pack contains a directory prolog that is added to the library file search path and thus can contain multiple library files. Some packs use rather poor (general, short) file names. Possibly is would be better to be able to use

?- use_module(pack(<somepack>/<somefile>)).

[abaljeu]

For what it’s worth, here’s the Visual Studio package naming (of packages I pulled into my program):

Nothing fancy, just whatever the contributor wanted to name their project, and the version. And if someone provided more than one thing it’s typically Project.Library.Version. But, the names are better than the Unix-inspired pack names we have.