Package/script/resource management?

[calebzulawski]

We need some form of dependency management with some of the following features:

• specify dependencies by name and version
• custom locations (preferably globally configurable)
• display documentation of dependencies

It might also be nice to allow easily installing ergo scripts to somewhere on PATH.

I'm not sure how dependencies should be specified (would a workspace key preclude actually accessing the dependencies in the workspace?) but it would be nice if they could be accessed as simply as depends:<name>, which under the hood looks something like std:load-remote or load

This could theoretically be implemented by a separate script, not within ergo, but my motivation for this feature is already a bootstrapping problem--this seems to be the most generic soluation.

[afranchuk]

Without a central hosted registry, it is difficult to standardize a particular implementation. That's why the current suggested approach is to use std:load-remote, which itself can then arbitrarily bootstrap things. However, a poor-man's registry could be hosted right on/through github.

There is precedent in std for using configuration (in std:net:http). So something similar could be used for configuring registry locations.

[calebzulawski]

I realized a good starting step might be simply having a location where scripts can be "installed" and accessible by default, like workspace but global. Then you can install an arbitrary package manager ~/.ergo/scripts/package.ergo and simply call e.g.

c++ = scripts:package CACI-International/ergo-cpp # do some magic

Would it be crazy to skip the whole scripts builtin and simply allow extending the language with arbitrary functions/keywords? Then it could be as simple as something like a packages.json in the project root, and a package built in that lets you call e.g. package:c++.

[afranchuk]

What you describe is almost the original intended workflow for external fetching! The (typically) ~/.config/ergo/lib directory is on the lookup path, though in that case the user needs to do load <name>. Having something which is automatically loaded isn't too crazy an idea. My only hesitation is that it hurts script portability (and it won't be obvious when a particular name doesn't resolve, versus load FOO failing), however I'm not against adding a feature which can be optionally used.