I’m building a package manager for interactive fiction called pif (Package manager for Interactive Fiction), inspired quite a bit by the look and handling of npm. It is found at: GitHub - toerob/pif: Package manager for Interactive Fiction · GitHub and you can install it via homebrew, shell script or just use the binaries in each release.
It covers finding/installing and publishing extensions for some of the major parser based IF systems right now: tads3, inform, inform6 and dialog. The instructions on how to use it is in the README.md.
It uses a registry located at in GitHub - toerob/if-extensions · GitHub . The registry only holds metadata, not the actual extension code itself. This registry I have created from public repositories announced in this forum or elsewhere together with the ifarchive links. (Please let me know if something shouldn’t be there.)
When publishing an extension with pif the user is provided with a set of prompts. After filling this in and approving a PR opens to the if-extension repository, requiring an admin of the registry repository to approve it.
Limitations:
While the schema holds information about dependencies, it doesn’t do dependency resolution, yet. You’ll however be notified of dependencies if they are provided in the registry. The registry is probably incomplete in this area though.
For discussion: I think it would be for the better for this registry to live somewhere else. I’m wondering if it can move to https://github.com/iftechfoundation in the future if this seems interesting? If accepted there this list needs maintenance of course. If and after such a move we should be a group of people maintaining it, to have some kind of filter of what goes in there. Perhaps one per platform.
We chatted a bit about this in email. My feeling is that if people expect to use the service, then it’s no problem to host the repository in the IFTF account. This thread will show how much interest there is.
Note that “use the service” includes “help maintain the repository, accept PRs for new extensions, etc.” This will definitely not work out in the long term if Tomas tries to do everything.
I really like this idea. In fact, I’ve always figured that a package manager for extensions would be the best way to manage this sort of thing without having to check individual GitHub repositories. My one concern is standardizing install directories for the installation of extensions. For Inform 7, this is relatively easy enough. For TADS 3 on Windows, my choice is usually Documents\TADS 3\extensions, installed into a subdirectory if there are more than 2 files (usually a header and a standard .t source file). I can’t speak for Mac or Linux, but I imagine this can be set up via environment variables, however.
Good idea! I think adding a configuration to override where to install the extensions per system should definitely be part of the system. Keeping the default behavior as it is now, by per-project (except for inform 7/10), but settable using either a “config” subcommand or by directly editing a yaml config in the application settings directory.
Also, for Inform 7 at least, there should be a configuration value for which version is used. This could work for Inform 6 and Dialog as well, but unlike I7, I6 has largely standardized around v6.44 and 0B/01 for Dialog. Also, I think PIF could stand to extend into macros and story formats for Twine, especially for folks like myself who prefer TweeGo and don’t exactly want to download the latest twine just for the story format updates, or, in both cases, search random git repos. Of course, this is just a suggestion.
I like your suggestions. But I have no idea how twine works, and what you’d prefer as a behavior of pif there. I guess it’s not too hard to figure out by myself, but if there’s any details I should be aware of, please let me know.
Yeah, with Dialog (compiler, not library) we try hard to ensure each new version is backwards-compatible. The only times it won’t be are when we introduce new syntax that conflicts with a definition you wrote in your own code, like if you had a predicate named (at most once) before upgrading to 1c/01.
Same with Inform 6, but to an even greater extent. Even outright bug fixes will be gated behind command-line options to avoid changing the behavior of any existing code, even when that behavior goes against the spec and the documentation! So much infrastructure depends on I6 now that any changes could have far-reaching, hard-to-debug repercussions, so better safe than sorry.
That’s not the case with Inform 7, because I6 inclusions let you access basically every detail of the underlying implementation. This means any change to the implementation can and does break someone’s code. I7’s solution is to provide multiple versions of the compiler and library, and let authors switch between them in the IDE. Sadly the same is not currently true for I7 extensions.
Oh, that’s right, I7 allows you to change what version of the compiler you use. As for twine, story formats should typically be downloaded into a folder called “storyformats” (or “story-formats” in Twine’s case; case can vary–I’m on Windows, where it doesn’t matter). As for custom macros, the user could setup a folder where they want to download them to, say, a scripts folder in Tweego’s path or their twine user data folder.
pif is now updated (0.2.8). Now you can pin both system and system specific versions using either the config command, or updating the config file directly.