Organizing Dialog-IF/dialog-extensions

Authoring Dialog
1

There’s now an embryonic extensions repository for Dialog at https://github.com/Dialog-IF/dialog-extensions. I populated it with the bits out of my own dialog-extensions repository to start with, so it’s currently a single-level flat directory full of library files and their associated unit test suites. That’s fine for a reasonably small number of extensions, but it might get unwieldy once lots of authors start contributing.

A couple of obvious alternatives would be A) to give each author their own directory, to which they can add whatever files and subdirectories they wish, or B) have a directory for each extension (along the lines of Howard Ship’s repository) right at the repository level. The former is more flexible; the latter makes it slightly easier to find things. Or we could even just use the repo to just hold a README.md file that points to individual authors’ own repos elsewhere.

How should we do it?

  • One directory per author
  • One directory per extension
  • Keep it flat until we have enough contributions to need a different solution
  • Don’t actually have extensions in the Dialog-IF/dialog-extensions repo, just a catalog file with pointers elsewhere
  • Some other option, which I’ll explain in a comment
0 voters
1 Like
2

For that matter, what should our philosophy about the repo be?

  • A cathedral: it’s a curated collection of things that don’t fit in stdlib.dg, but are contributions to “how to do X in Dialog”
  • A bazaar: it’s a marketplace of different ideas that folks can bring, for the benefit of anyone who finds them useful
  • Some third thing that I’ll explain in another comment
0 voters
1 Like
3

I voted for ‘by extension’, but honestly, the main thing I think you want to avoid is ‘by author’. That’s how I7 does it, which IMO is ‘cute but non-functional’. It’s frankly demoralizing to look for an extension and know you can’t just look at a list of titles; you have to individually click through authors first.

2 Likes
4

I feel like what you want is some sort of public rating system overlaid on a bazaar? But the base would be ‘the bazaar’; you can eventually build the rating system on top of it if/when it gets too unweildy.

1 Like
5

something which would be nice tbh would be that the extension’s docs (if there is any) get displayed in a subdirectory within the directory of actual extension itself

1 Like
6

Primarily, by extension should work, with caveats, based on how mine are organized.

I have source files that depend on other source files.

I have library sources and then related debug sources (that add grammar or debug-time logic and rules).

lib
├── dialog
│   ├── debug
│   │   └── stddebug.dg
│   └── stdlib.dg
└── ext
    ├── debug
    │   ├── annotations.dg
    │   ├── roominfo.dg
    │   ├── sceneinfo.dg
    │   ├── standard-actions-debug.dg
    │   ├── tc-debug.dg
    │   ├── trace-action-helpers.dg
    │   └── tutorial-mode-debug.dg
    ├── scenes.dg
    ├── tc.dg
    ├── tutorial-mode-standard-actions.dg
    ├── tutorial-mode-tc.dg
    ├── tutorial-mode.dg
    └── version.dg

So I have one version.dg for the entire set. scenes.dg, tc.dg and tutorial-mode.dg are top-level libraries. annotations.dg is used by several others. tutorial-mode-standard-actions.dg are tutorials for common commands, and -tc.dg adds a few in combination with tc.

I may ditch trace-action-helpers.dg as the Skein helps more.

So, it’s complicated, we could have tc/lib/tc.dg and tc/debug/tc-debug.dg, and so forth.

One could imagine a dgt add-extension command that would know how to read the %% dependencies: comment at the top of the files and copy everything as needed like a simple package manager.

I don’t want to get too grandiose here, especially since its always implied that authors may reach in and delete or rewrite chunks of libraries if the need to.

1 Like
7

How would the extensions get added and updated?

Are multiple versions of the same extension meant to be available at the same time? Or is it just the latest version?

8

It’s a Github repository, so folks would check things in through git. We’ll need to manually add new contributors to the Dialog-IF project.

It’s a git repository, so past versions would be tracked as new ones are committed and pushed. If a particular past version is of interest (example: unit-0m03.dg, for folks on 0m/03 or 1a/01), additional copies can be checked in, or important versions can be tagged, or both.

1 Like