I’m trying to get a quick understanding of how Inform 7 Extensions are available on the web app and through github.
For example, the Emily Short Anniversary Contest thread recently mentioned that Emily Short “Wrote 38 of the 132 Inform extensions listed at https://i7el.herokuapp.com/”.
That still doesn’t account for the others. I expect that that comes from the fragmented nature of Inform’s extensions, which have had like 3 or 4 ‘official’ websites over time.
I don’t believe the GitHub repo was intended to contain all the official extensions. There’s an explanatory post here about which types of extensions can be found where (although the Inform7.com website has undergone changes since that post was written, and I don’t know if there are actually any extensions available there right now, so maybe disregard that part).
I believe the https://i7el.herokuapp.com/ website was intended to be more comprehensive, but it hasn’t been kept up to date.
I would check the Public Library if you are looking for the most “official” source of extensions currently available.
From §27.1. in the “Writing with Inform” manual:
“Writers who wish to make their extensions public on the Inform website should also be clear that by doing so, they are donating their work to the community on the basis of the broadest form of Creative Commons license: that is, they retain copyright and the right to be identified as the author (and as we shall see they are automatically credited in any work of IF which uses their extension), but are giving unlimited permission to use, circulate and republish their extensions in any form, even as part of commercial works (should that arise).”
I believe this applies to the extensions in the public library (even though it says “on the Inform website” and I’m not sure if the public library is technically part of the Inform website).
The https://i7el.herokuapp.com/ site is liable to go away any time now; it is using a server version that is being retired by Heroku and I am not going to be doing any updates to it. AFAIK there are no extensions that are only accessible on it.
I must note, that based on the timestamps on emshort.com and I7el.kerokuapp description, that probably the majority of those extensions aren’t up to date, being of 2015 vintage for 6L38, 6L02, 6G60, only “simple graphical window”, vintage 2018, being for the current 6M62…
Surely she has her reason for being not much active, so let’s find volunteer for mantaining these extensions, if they are not obsoleted in the meantime by other’s extension and/or I7 library.
I am hoping that we wind up with a coordinated, ongoing volunteer effort to maintain extensions, to go along with the open-source I7 release. (I also hope that’s coming soon…) I chatted a little bit with Graham about this last year, but I don’t know what his plans are.
Currently that extensions github repo is organized by author at the top level. If I am understanding right, would it make sense to give it a top level hierarchy that distinguishes between the “public library” that appears directly in the Inform IDE and everything else (the current repo contents)?
Does the Inform 7 extension format provide a method of recording which version of Inform it targeted (like “6L02”), or a minimum I7 version / maximum I7 version (if known)?
No, and unfortunately not even the Standard Rules had updated version numbers (even though they were updated between releases!) For the Heroku app that was just me adding in manually the versions I knew the extensions could be used with.
Your best bet is just to go by date. If it’s dated to after an update of the core I7 compiler then it probably will support it.
Hmm. I see how if the dates were aligned to I7 compiler releases then you could infer a fair amount from it, hopefully.
Could the extension format add something in the future that would allow it to contain this information?
I’m thinking something very simple that could be both descriptive and prescriptive:
The minimum recommended Inform version is 6G60.
The maximum recommended Inform version is 6L02.
…and / or descriptive:
The target Inform version is 6L38.
…it could then potentially be parsed – for example, the Inform IDE “public library” interface having a way of choosing a latest version of an extension between multiple public versions, or downloading an appropriate version for an older IDE. Or giving a warning on including something out of scope, or chaining extensions out of scope. Or have a release tool add/suggest that the target version be included. But even if it wasn’t parsed by anything, it could be helpful just to be informative.
I don’t think that information should be parsed out of the extension. That implies a mess of updating old extensions. If you ever get it wrong, you have to release a new version of the old version of the extension. You’re trying to invent a declaration which will be compatible with all older and newer versions of the compiler, which is pretty much a compatibility nightmare.
(Starting with the fact that all pre-2020 versions of Inform will not recognize those declarations, so how can you put them in at all?)
Putting that information in the extension is sensible – in comments! – but tools shouldn’t rely on it. Instead, there should be metadata in the extension collection database.
It would help though if extensions could more reliably specify their dependency on the Standard Rules/compiler features. If the version numbers were all semver and an extension could say “I need something compatible with version 2.1.5 of the standard rules” then the compiler would be able to easily detect potential problems. Now an extension might still work when the standard rules bump to semver major 3.0, but that’s something that requires manual investigation.
Metadata makes sense. Perhaps a standard simple text metadata file (.txt or .ini, etc) that can accompany an extension file?
Is it currently a requirement that an extension file name match its title? It seems like right now the public library unpublished older versions into an archive folder: /authorname/archive/extensionname_oldversionno.i7x but if you have distinguishing version information on multiple copies (as many as you want) then you can list them all together in an author folder but only offer the latest version for download from the Public Library – the file names can be informative or even structured but they don’t need to be as long as they are unique.
Re:semver – Do the standard rules / compiler advance together? If they are released together from one repo then semver could be retroactively attached to specific commit numbers.
Regarding max and version metadata for an IDE library – for example, the Processing IDE (PDE) accesses a central listing of contributed libraries and tools for that exist in multiple versions and have updates – but having varying compatibility with Processing 2, 3, 3.4 / 3.5 etc.
Contributions Manager (analogous to the Inform “Public Library” tab) consults a list of properties .txt files to build its listings and indicate which resources are available / recommended for a given version of the software.
So, for the Rosetta Examples for Processing library, there is a simple INI-style metadata file, rosetta_examples_p5.txt:
name=Rosetta Examples for P5
authors=[Jeremy Douglass](http://jeremydouglass.com)
url=https://github.com/jeremydouglass/rosetta_examples_p5
category=Other
sentence=Common coding tasks in Processing (Java mode) from the Rosetta Code chrestomathy website.
[...]
version=10
prettyVersion=v0.10
minVersion=0
maxVersion=0
and this txt file URL silently corresponds (same name, same path) to a library file with a different extension, rosetta_examples_p5.zip (the equivalent of the .i7x).
If the author doesn’t specify a max Processing version (typical), then it is 0 – if at some later point Processing 4 comes out and the example set doesn’t work anymore, that max can be added without changing the library release number.
Also note in this example, no min is specified – because it is an example set. Some of the material works with Processing 1, 2, and 3, some with 2 & 3, and some only with 3, so the responsibility is on the user. But most library authors do specify a min because they don’t want support requests from something that won’t work.
Me too. On github I see a whole lot of things that are time-stamped “2 months ago,” but this clearly refers to the date on which they were added to github, ported from the Public Library, not the date on which the Extension was last updated. There are a lot of Extensions on github that are not in my I7 IDE (though the IDE thinks it has everything current). Conversely, there are a few things in my local I7 that are not on github – including my own “Spellcasting” Extension.
How exactly would one go about making sure that one has an up-to-date I7 installation, including Extensions? I mean, other than running WinMerge to find out if two versions of a file are identical, and doing that for a whole bushel of files…
Speaking as the person who merged the then-current I7 Public Library to the github 2 months ago, the intent is that a “fully up to date system” simply uses the release zip and/or git checkout as your Extensions folder, as is documented in the repo’s readme. You can then completely ignore the Public Library listing, except perhaps as a convenient categorised way to find (but not install) extensions of interest.
This includes all extensions contributed on GitHub plus the latest versions of everything in the Public Library (plus some contributed patches to those). This is not all extensions ever created – the Public Library occasionally dropped extensions when they didn’t compile for the newer versions of Inform, or didn’t meet certain standards such as adopting response text. But it hopefully is every extension currently expected to work (plus some experimental ones).
If you know of specific extensions that you think ought to be included and aren’t currently in there, you’re welcome to contribute them yourself via a pull request (or better: to encourage their original author to do so, giving them a chance to update them if they so desire).
Thanks – I hadn’t noticed that. Oddly enough, however, in the Windows IDE the instructions given seem to be incomplete. The assumption in the instructions seems to be (correct me if I’m wrong) that once I rename Extensions to Extensions Old, rename extensions-master to Extensions, and launch the IDE, the new Extensions folder will be active in the IDE. But that’s not what happens. My previous list of extensions is still extant in the IDE.
If I select one of the items from the IDE that is not actually in the current Extensions folder, the compiler can’t find it, so this is a problem within the IDE. However, if I then go to the current Extensions folder and ask the IDE to install a set of extensions (I selected those by Xavid) from the Install Extensions command, the IDE updates, from top to bottom, to show the full contents of the current Extensions folder.
