Hey! I built a vendoring tool for Odin called Odyn.
The pitch is simple: odyn get user/repo clones a dependency into odyn_deps/ and pins the exact commit in Odyn.lock. odyn sync reproduces that exact state on any machine. It doesn’t have a registry or solver, so it’s not a “package manager” in the traditional sense.
odyn init myproject
cd myproject
odyn get odin-community/math
odyn sync
odyn init scaffolds your project and generates ols.json with the deps: collection.
Commands: init, get, sync, status, update, remove
Platforms: Linux (x86_64, aarch64, i686, RISC-V, musl), Windows (x86_64, i686), FreeBSD (x86_64, i686). macOS coming in 0.2.0.
Repo: razkar/odyn: Not a package manager for Odin. Odyn is a reproducible vendoring tool for the Odin programming language that can be replicated with Git and a man with a spreadsheet. Dependency manager maybe. - Codeberg.org
It’s a 0.1.0 so it’s early, but the core workflow is solid and tested. Would love feedback from people who actually use Odin day to day!
2 Likes
i opened the codeberg page, noticed the word “cargo” and immediately closed the tab.
veni, vidi, cessi. 
p.s.
just use git submodules.
1 Like
Fair enough, Odyn is essentially git clone + a lockfile under the hood. If you’re happy with submodules you’re already doing the same thing, just manually.
what do you mean by “manually”? your tool imitates the functionality of git submodules and adds complexity by using an unnecessary collection as a crutch.
The collection just maps deps: to odyn_deps/ in ols.json so the language server knows where to look, a QoL decision. As for submodules, yes, it’s similar, except odyn sync works without knowing submodule science.
what “science”?
cd myproject
git submodule add <package-url>
the new package is ready to use and ols works. its version is locked and the commit id is stored in the git index of your project.
git clone --recurse-submodules <project-url>
is all you need to clone your project and restore all dependencies later.
your tool is a bad idea, it imitates and obscures git functionality and adds unnecessary complexity. it also goes against odin’s philosophy (Package Managers are Evil - gingerBill).
…and, seriously, the fact that this is coded in rust instead of odin just reinforces my feeling that i’m wasting my time here anyway.
From Bill’s article you linked:
‘Copying and vendoring each package manually, and fixing the specific versions down is the most practical approach.’
That’s literally what Odyn automates, nothing more.
now you’re just resorting to trolling. the reference to the philosophy wasn’t the main point of my last post and you are taking a single, selective sentence out of context, twisting its meaning and using it as an “argument from authority”, a logical fallacy. i am not playing that game- i’m outta here.
I’ve used this tool a bit and I really like it!
I think Razkar is doing it right. Everything automated is something that could be trivially done by hand. There’s no package resolution, automatic updates, or other magic going on - I still have full control. It’s all just stuff I would have done manually.
Some reasons I like Odyn:
- I don’t like Git Submodules
- Odyn pulls directly from GitHub and other common repo hosting sites. Just give it a username and repo name, and it downloads.
- I can easily avoid committing vendored repos to my project until necessary. That keeps my repo lightweight and quick to clone. And maybe my project isn’t big and I’m not yet ready to go all in on vendoring something because I’m still prototyping. Or, maybe I just don’t want to actually vendor something because I know that I can always vendor that code later and I understand the stability risks of not vendoring (and, since the repos are copied locally, even if they were somehow taken off the internet and Wayback machine didn’t work, I could just commit the local version to my repo then).
- I can fearlessly make quick experimental changes to my local vendored libraries, and then revert them back to a clean state with
odyn sync.
- Updating a vendored lib is super easy, but still explicit.
- I can pull in other people’s third-party repos quickly and test them out for prototyping without a single Git command.
- Looking at the lock file is an easy way to see what third-party dependencies you depend on (outside of Odin’s vendor collection) and what commits the libs are pinned to. I don’t need to search files or use Git to find the version.