Arc Forumnew | comments | leaders | submitlogin
Another proposal for hack sharing
2 points by shader 3045 days ago | 2 comments
What if we reorganized the directory structure of anarki so that it looked something like this:

  arc
  bin/
  lib/
  packages/
etc.

Nothing but what is absolutely necessary is dumped into the main folder. We can add other folders, like "extras" etc., but in theory everything should go in the lib or packages folders.

"arc" is the name of a shell script similar to the one I posted on the forum earlier that either launches the repl or ac-evals a arc file passed in on the command line.

bin contains only the extreme core of arc, the scheme files and arc.arc. Everything else goes in the lib folder.

lib contains all of the simple single file libraries that are just included with anarki. Anything important enough or simple enough can just go here. This is where the lib function should look if it's passed a simple symbol, or you can use 'load directly.

packages, or something named similarly, is a folder that is ignored by git, but created by arc when the first package is downloaded. It contains git repository folders, and lib looks here when a package is referenced. If the package isn't here, it looks on one of the servers as mentioned in the previous proposals and clones it.

By having a folder designated for git repos it's easy to develop your library in the context of arc, and since 'lib will be designed to look there it should also easy to load. Since they are allowed to be git repos (they don't have to be) it's easy to keep them in vc, publish them separately on github, package them in bare repos, and keep track of development history and tags.

When given the library name and version number, arc could presumably clone the proper repo if it hasn't been cloned already and check out the correct version, or read it in directly from git.

A web service can then be written that reads the meta-data of all of the in the packages directory, and then makes them available through a website and public api. The lib functions can then find packages hosted by other users given their location, and it is very easy for packages to be distributed.

It should be possible for the lib functions to support other methods of storing packages besides git, such as bare .arc files, simple folders, tarballs, etc. All that should need to be changed is the meta-data in the package folder. Since the meta-data is really what determines the contents of the library, packages can be grouped however you like, including by user name.

Also, since these packages are entirely handled by arc, we should be able to make functions that would to generate the meta-data and descriptions of the packages given the source code, distribution format, user name, etc., so that publishing becomes easy as well.

What needs to be determined for this system to be developed is: what meta-data do we need, and how do we represent it? After we have our meta-data format, it should be possible to make a few preliminary versions of a package sharing system.



1 point by Adlai 3044 days ago | link

I'm a tiny bit confused. You refer to arc handling the packages, which suggests to me that the core stuff deals with the packages. I think you mean that whatever tool gets written in arc for managing arc hacks would handle the packages. Am I putting words in your mouth?

-----

1 point by shader 3044 days ago | link

Yes, that is correct. I'm sorry if I confused you. Maybe in the future the core of arc would handle packages to provide namespaces, but I meant more that since arc functions will be handling the use of the meta-data, it should be easy to turn that around and generate the meta-data from how you're using it, and a little more information about who you are and what you're trying to do.

-----