Inf7, a CLI project manager for Inform 7

inf7’s goals are to:

  • make it easy to create and compile projects on the command-line
  • make usable Project Indices available to CLI users (including links to documentation)

The documentation-handling it has to do for the latter offers a couple of benefits of potential interest beyond just to command-line users. It generates one big web page of all of Writing in Inform and The Recipe Book, facilitating searching the whole of the documentation. And it can create an epub of the whole thing that’s almost 2/3 smaller than the epub included with the IDE packages’ documentation.

Full documentation and the code is available at the inf7 github repo.

Once you’ve set it up, e.g., with

$ inf7 setup --internal /usr/local/share/inform7/Internal --external ~/external --resources /usr/share/gnome-inform7/Resources --docs /usr/share/gnome-inform7/Documentation --author "Zed Lopez"

creating and compiling a project would look like:

$ cd ~/inform
$ inf7 init "A Walk in the Park"
Created /home/zed/inform/A Walk in the Park.inform
$ emacs A\ Walk\ in\ the\ Park.inform/Source/
$ inf7 compile A\ Walk\ in\ the\ Park
/usr/local/bin/ni --noprogress --internal /usr/local/share/inform7/Internal --external /home/zed/external --project /home/zed/inform/A Walk in the Park.inform
Compiled 23-word source.

/usr/local/bin/inform6 -wE2SDG /home/zed/inform/A Walk in the Park.inform/Build/auto.inf /home/zed/inform/A Walk in the Park.inform/Build/output.ulx
Inform 6.34 for Linux (21st May 2020)
In:  1 source code files             66296 syntactic lines
Out:   Glulx story file 1.210503 (537.5K long):

/usr/local/bin/cBlorb -unix /home/zed/inform/A Walk in the Park.inform/Release.blurb /home/zed/inform/A Walk in the Park.inform/Build/output.gblorb
cBlorb 1.2 [executing on Monday 3 May 2021 at 13:44.58]
Completed: wrote blorb file of size 642210 bytes (1 picture(s), 0 sound(s))

and the project’s Index would be viewable with, e.g.,

$ firefox "A Walk in the Park.inform/index.html"

This is barely-tested alpha code that I haven’t yet used to develop a real Inform 7 project. I don’t know of any bugs, but I’m sure they’re there.


Looks admirably thorough, just from looking at the docs.

  i6flagstest: -wE2~SD
  i6flagsrelease: -wE2~S

The Mac IDE uses -kE2SDwG for test, -kE2~S~DwG for release. I strongly recommend S (rather than ~S) for testing – that adds a lot of checks for errors that might otherwise crash the interpreter.

I also recommend including ~D for release mode. You don’t need it (since ~D is the default), but it’s better to be explicit.

The k option isn’t a big deal. It generates debug info, but at present not much makes use of that debug info, and it can be slow to generate.


Thanks; I’ve changed the defaults accordingly.

1 Like

Any chance of getting this on Windows?
Edit: My bad, I thought this was native code, rather than using Ruby. Guess it pays to RTFM.

If you try it, let me know how it goes. I don’t know any reason it wouldn’t work on Windows – I used File and Pathname join methods throughout, and TTY::Which, which it uses to find executables, is supposed to work on Windows – but I haven’t tried it on anything but Linux.

I failed my saving throw against adding more features. I just pushed a new version.

You can now specify a plain .ni file with compile instead of a project name. In this case, it’ll create a temporary project to compile it and leave the resulting .ulx or .z8 file (if compilation was successful) in the current directory.

There’s a new subcommand, smoketest whose --ext flag you pass an extension filename. It’ll create a temporary project with a storyfile that includes that extension and try to compile it. You’ll either see error messages or the successful compilation output (nothing is saved).

And I fixed a bug: it wasn’t considering extensions when compilation was checking whether auto.inf was up-to-date. Now if or any extension in the extension project dir has a modification time after auto.inf, it’ll compile. It’s still insensitive to potential changes to the external or internal extension dirs; use the --force flag to compensate as needed.

Another new version pushed.

“smoketest” was renamed just “test”.

If it’s configured, it’ll use a hacked version of @zarf’s to pretty print the Inform 7 source code for the story file and Extensions as available through the Project Index. Installing and configuring is a little cumbersome, but is explained in the INSTALL doc.

There’s now a “clean” subcommand to clean up a project’s build and index dirs.

I just pushed version 0.1.6. One big new feature:

You can run setup without an existing Inform 7 installation with:

$ inf7 setup --download

For everyone, this obviates specifying the --internal, --docs, and --resources flags; it downloads an archive and creates/configures them appropriately. If you’re on Linux, it further downloads the CLI package and uses its binaries; you wouldn’t need anything else. Mac and Windows users are on their own to supply ni, inform6, and cBlorb, but at least they don’t have to look up where their Internal, Documentation, and Resources directories are.

Once you get inf7 itself installed (which I need to make easier), there’s now a very easy route to a working Inform 7 development environment for Linux users.

Small changes (including from 0.1.5; I haven’t been posting about every update):

  • several improvements to Inform 7 pretty-printing
  • it no longer transforms the extension pages in the external dir’s Documentation/Extensions: it just uses its own, which now have Javascript to copy examples to the clipboard
  • references to e.g., “next chapter”, “chapter on Activities”, “the chapter on Actions” in documentation are now links (unlike the original)
1 Like

New version, 0.2.0, with several nifty things:

It used to be when you navigated from a Project Index into the docs you lost the navbar. Now the navbar is maintained appropriately and you can get back to the project.

If you configure “browser”, “zterp”, and “gterp” to appropriate executables, when you compile a program then, on failure, it’ll automatically launch the browser with problems.html; on success, it’ll launch the appropriate interpreter. There’s also a play subcommand that will invoke gterp or zterp; mostly of interest to test they’re configured properly.

You’ll be using an independent editor, of course, and dropping to the command-line to compile, but otherwise this offers a similar edit-compile-run/check things in the Project Index/docs development cycle that IDE users get, and access to all the same information barring the skein.

More improvements to Inform 7 pretty-printing and there’s now a ‘pp’ subcommand that will output pretty-printed source code as plain text (and though tables look good in its output, their presence makes the output unusable as source code itself because currently tabs are destroyed) or html (but this is probably less useful because it depends on inf7 css).

Compiling a project no longer checks source code and output modification times – it always tries to compile. It checks only the project’s own extensions to consider reformatting their HTML. By default it skips them if modification time says they don’t need it; --force makes it rewrite all of them. If you want to rewrite the HTML for the External and Internal directories, use the new census subcommand. As with compile, it skips things whose modification times indicate they’re up to date unless you use --force.

The new update subcommand freshly copies the extensions from your .config/inf7/extensions directory to a given project.

The set and settings subcommands can be used without a project. With --init, set lets you update .config/inf/inf7.yml.

I’ve re-styled the Project Index somewhat. Some of the results are better than others; this will need more work.

This will probably be the last update for a while. As the original README noted, the code needs refactoring. I now have a better idea of what I want it to be and want to re-organize some fundamental things.


Just pushed 0.2.1. Changes:

  • back-ported the script that generates the the Standard Rules web page; now that’s the same version of the SR inf7 users get (but with local links to documentation)
  • pp --html now produces a standalone web page with its CSS in the head and no external dependencies
  • setup --download now updates Quixe and Parchment (in external)
  • added ‘Definitions’ to the navbar with content per the IDEs
  • revised HTML formatting of source; line-numbers via CSS now, so copy-pasting code would work (where tabs aren’t relevant, at least)
  • much improved re-styling of the Project Index, all the ugliest bits of previous re-styling fixed
  • no longer defaults to $HOME/Inform for your external dir; if none is specified it uses a temp dir every time
  • various bugfixes
1 Like

Ruby’s throwing an error when I run inf7 setup: - View paste mwRzX

I’m using Arch Linux, for reference, with Ruby 3.0.0.

Looks like 0.2.1 blew up unless one specified i7tohtml in the setup line (and it’s supposed to be optional).

I just pushed 0.2.2 to fix it. Assuming you didn’t change anything under $HOME/config/inf7/, or aren’t attached to whatever changes you made, please try just:

git pull
rm -rf ~/.config/inf7

rebuild the gem, re-install it, and run your setup again.

That bug was fixed, but now there’s an issue with Ruby attempting to read a Python file during install and compilation.

It works if you run the commands in a Python virtual environment with i7tohtml, so it’s usable – but definitely a bug.

Yeah, that’s pretty awful. Thanks for reporting. Obviously, I did my testing with i7tohtml configured. I suppose I could define it as a requirement and “fix” the bugs! (Not serious.)

Invoking a separate process and introducing a dependency on another language was never ideal. I had imagined I’d just translate the relevant bits from, which seemed easy enough… but pygments for ruby just invokes a separate Python process anyway so there didn’t seem to be much advantage. I have a half-written lexer for Rouge, a ruby-native syntax highlighter… but I’ve been focusing on the extension directory testing feature in recent development.

I’ll look into ensuring i7tohtml is really optional this weekend. It’ll probably be easy to fix. If it’s harder than I think (which it might be – the extension-parsing code in the release branch is kind of ugly – the worst of that is cleaned up in dev) I’ll push a doc change noting that i7tohtml is functionally a requirement for now (as a work-around, not a fix).

I haven’t heard back from Verte, but I think this problem really was fixed by my update. The final installation step is placing a script somewhere in your PATH; in describing above how to pull an update and re-run the setup, I failed to mention that one would need to replace the script, too; following those directions as written, they would have still been running the old version.

(Smoother installation and better write-up thereof is coming eventually. I’ve been spending my hacking time using inf7, finally really learning to code in Inform 7 instead of just hacking I7-adjacent projects.)


Any chance this could support .i7xp projects as well as .inform projects?

As far as I understand it, the main difference is that Foo.i7xp/Source/extension.i7x is the source of truth for the extension rather than Foo.materials/Extensions/<author>/Foo.i7x. So at test time, Inf7 would need to copy the former to the latter.

1 Like

Hmmm. It is both the case that:

  • I had heard of “extension project” and wondered what it meant and I futzed with the IDE briefly and thought I learned the answer, but it seems like I was entirely wrong
  • I’ve been thinking a bunch about how much I’d like actual package management, and a build system that facilitated automated testing

So thanks for the suggestion; I’ll put extension projects on the list.

What I said above is still true: I’ve been using inf7 and hacking I7 code with most of my hacking time.
There has been inf7 development going on, but I’m in the middle of something big and hairy: I wrote my own ruby-native lexer/syntax highlighter with rouge so I could avoid the dependency on the external script. And it mostly works, but chasing down the bugs has been hard.