Installing and Using Programs from the Source Oc Directory on OpenComputers
If you have spent any time running OpenComputers machines, you eventually need to move beyond the default program library and pull in tools other people have written. The Source Oc Directory is the closest thing there is to a central repository for these programs. It is not an official Minecraft or ComputerCraft addition. It is a community-maintained listing that the install command can query. Before you type a single command, make sure your OpenComputers version supports the install command. Anything below 1.6.2 will fall apart here, and you will waste an hour debugging something that was already fixed. Check with oc_version first. It prints the build number and saves you a lot of unnecessary trouble. The install command itself looks like this:
install https://raw.githubusercontent.com/tom54541/OpenComputers-SOD/master/source.list That URL points to the source list file. When you run it, the system parses it and adds the entries to your local configuration. Some programs will install cleanly. Others will complain about missing dependencies, which is normal and not a sign that anything is broken. You just need to install the missing pieces first. I ran into a specific problem last year where a program depended on a library that had been renamed between versions. The install command reported a failed dependency but gave no clear indication of which library was involved. The workaround was to open the source.list file directly, find the entry for the failing program, look at its dependencies field, and manually install the older version of the library first. It took about ten minutes once I figured out where to look.
After that, the actual installation usually takes less than a minute per program on a decent machine. On a low-end machine with a slow HDD, expect closer to three minutes because the file transfers happen over the network and the disk write speed becomes the bottleneck.
Get the Full Details
How It Actually Works Under the Hood
The Source Oc Directory is essentially a flat text file. Each line contains a program name, a URL pointing to the source code, and sometimes metadata like dependencies or version constraints. The install command fetches that file, parses it, and then downloads each program into /tmp before moving it to the target computer's filesystem. Here is a line from a typical entry: netcat:https://raw.githubusercontent.com/example/programs/master/netcat.lua:dep:networkutils
The first field is the name you type when installing. The second is the raw source URL. The third is an optional dependency marker. If a program lists a dependency you do not have, install will either auto-fetch it or stop with an error, depending on how the source list was configured. One thing most people miss is that the install command does not verify checksums by default. The source list file could be modified and you would never know. I started adding a manual verification step after finding a fork that had injected a credential-harvesting snippet into a popular utility. Run wget --no-check-certificate and diff the output against the original before installing if the program handles sensitive data.
Common Pitfalls That Are Not Obviously Problems
The first issue is path resolution. Some programs in the directory assume they are installed to a specific directory, usually /rom/modules or a custom path defined in the program's shebang. If you install them blindly, they will fail at runtime with a module-not-found error. The fix is to read the program's documentation file before installing, not after it breaks. The second issue is the async event handling. Many programs in the directory were written before the OpenComputers event system stabilized. They call os.sleep() or event.listen() in ways that conflict with later game ticks. Your program will appear to work until something else on the same computer tries to use the event queue, and then both programs deadlock. There is no automatic detection for this. You just have to test each program in isolation before combining it with other tasks. I learned this the hard way when a weather monitoring program I installed started blocking my automated farming controller. The weather program was doing a blocking read on a network card event, and the farming controller was waiting on the same event type. Moving the weather program to a separate computer solved it immediately. You can also set event filters, but that requires understanding the internal event IDs, which the directory programs rarely document.
Alternatives When the Directory Fails
If a program is not in the Source Oc Directory, or if the directory entry is outdated, you have a few options. The most reliable is to clone the upstream repository directly onto the computer using git if the program is hosted on GitHub. This bypasses the source list entirely and gives you access to the latest version. The tradeoff is that you lose the centralized dependency tracking. Another option is the OpenComputers modpack curator tools, which bundle pre-tested programs together. These are slower to update but tend to have fewer compatibility issues because the pack author has already resolved them. I recommend this for production servers where downtime matters. The Source Oc Directory is better for experimentation and rapid development.
Practical Tips for Staying Organized
Keep a local backup of the source.list file. The upstream version changes occasionally, and if the repository goes down or gets deleted, you lose access to every program in it. I maintain a mirror on a separate GitHub account specifically for this reason. It cost me nothing to set up and saved me when the original became unreachable during a server migration. Use list to see what is already installed before running another install command. It outputs the program name, version, and installation path in a compact format. Without this, you end up with duplicate installations that overwrite each other silently and create very confusing bugs. The Source Oc Directory is functional but incomplete. It covers the most common utilities and many niche tools, but it does not cover everything, and the maintenance cadence varies by program. Treat it as a starting point, not a complete solution. If a program is missing, check the OpenComputers Discord or the mod's issue tracker before assuming it does not exist.
