Created my package manager for my own use. Yes I know, I know. The creator doesnt like it, still if anyone needed management.
Still its early on development. Bugs may be found, please report and contributions are most welcome.
2 Likes
Here is my take:
The way I see it, Odin is a systems programming language and not a web development language so it following web dev pipeline feels very weird(to me).
Ignoring the ⚠️ Warning: This tool is AI-generated part, prerequisites like Bun will make it so that initializing the package manager itself will take several folds more time than the compiler would take to compile the entire code base and this can get annoying when this constantly happens. Build flags entry is restricted to a field in a json file only(from what I saw on the surface level) and its not as convenient as simply passing the build flag argument to the compiler itself(for me).
I can see how version management can come in handy for languages like Zig and Rust but for a programming language like Odin, its hardly needed. Most of the fairly needed packages are already in core and vendor. I’m comfortable with using git version control system and I dump any library that I used more than twice into shared collection so a package management that maintains multiple clones of dependencies for every new project seems like a wasteful feature to me.
Since Odin doesn’t require any build or config file or whatsoever and creating a new project is just a matter of creating a new directory, having to call something like init for creating a project seems unnecessarily complex to me.
Odin compiler already does most of the caching and locking by default while keeping all such business confined to the respective temporary directory of the OS platform while not creeping into the project’s directory so a package manager doing any additional caching on top of that seems completely unnecessary IMO.
I’ve only used Odin for around 2 years now and I think for my personal preferences, my ideal package manager would be something that is light and fast. Something that requires very minimal config setup and simply uses something like curl instead of bun for fetching or updating dependencies or resources. Though its not strictly package management related, automatically rebuilding the project upon updates in the code base(as in a watcher like fs.watch in npm that re-builds the project) would be really nice to have too.
Unfortunately, this clearly is not for me but I hope it fulfills your use cases. 
3 Likes
Appreciate the feedback. In my opinion, following the web dev pipeline for a systems programming should not be frowned upon, cuz after-all we are making application that can be easily developed and easily distributed. Though odin binary has all the option, there no crime in automating it and making it a bit easy. This can be thought of as a simple wrapper. and also bun is for building the binary from source, prebuilt single binary is already released for linux, windows and macos
Unlike the web development that is well confined within a sand-boxed environment provided by the web browsers, systems programming languages run directly on the underlying hardware and that by itself makes a significantly huge difference, huge enough to not associate one thing with the other.
I see. Lucky you!
I work on creating high performance software so my requirements and approach for making applications that can be developed and distributed are limited to the native architecture only so unfortunately, the easy development is out of options for me.
I was just stating that I find that to be an unnecessary complexity as the Odin compiler is intuitive enough to not require any additional wrapper but you do you.
I see. I think of this as a totally unnecessary complexity too because the Odin compiler is well capable of building binary from source while providing several optimizations and target backends options.
Yes, it is a “crime” and should be frowned upon, and a community has formed around Odin that is brave to say so, that enough is enough and we must try to undo the damage caused by the web developer mentality. Also the last thing the world needs is more AI- generated typescript slop. Show at least a little self-respect and develop your tool in Odin itself.
2 Likes
Yes, it is a “crime” and should be frowned upon, and a community has formed around Odin that is brave to say so, that enough is enough
So brave…
You’re acting like this is a war between good and evil, but we are actually just talking about optional programming stuff. It’s not that deep. Use a package manager or don’t. Use a package manager like a crazy person or don’t.
1 Like
Although the answer wasn’t put in a nice way, it carries some truth.
Why write it in typescript when it’s a PKG manager for Odin?
I would assume someone sits down to write a package manager for a language that needs it. You know that a language needs a package manager if you spent a long time with it and used a lot of 3rd party libraries and realised how much of a pain it is…
If you reached this point, you probably like the language enough to put effort into a PKG manager, as you didn’t just drop it.
Now if you like the language and spent time with it, why write it in another language? I’d say familiarity. But then why AI generate the whole thing?
It just doesn’t add up.
I’m sorry but this is just AI slop. And I bet it doesn’t do anything well at all. In fact, there are a few things that you’d need to do in the compiler itself (very minor by the way, probably <50LOC) to ensure you’ve got a proper versioning handling with the ABI.
And no sign of a database used anywhere? That’s already a bad sign.
If you want to use AI slop, please only do it for things that don’t matter and not going to be used by any one.
3 Likes
People just calm down. Its completely optional to use this. Used the bun runtime to build it quickly. I am using this for several reason. Firstly and foremost managing my odin compiler version. and scaffolding an initial project with good defaults. It may be AI slop, but it serves me well. So shared it. And as @gingerBill pointed out, it is a flawed software, cuz im a complete novice. just starting out. But im sure i will get better, and make this software better for myself. Thanks guys for these feedback.
Huzoor. The moment you actually get better is the moment you realize that this thing you are working on is not useful for a programming language like Odin.
Like I mentioned earlier, managing multiple compiler versions becomes essential for programming languages like Rust and Zig but not for Odin. Its completely unnecessary.
WIth initial project literally being a new folder itself, seeking for “good defaults” is an absolutely needles complexity.
It’s good that it’s serving you well, but the people who shared their opinions on this thread are not novices. Them failing to see the “value” of your work should signify something. I’d argue that the compiler already ships with far more valuable functionality by default, which makes your wrapper effectively pointless.
1 Like
This is a growing pain for Odin, and I hope it is temporary. Package managers are actually just workarounds for various git anemia. If we could easily, and without significant downsides, add another repository as a “part” of our repository, this conversation might not even be happening. On the other hand, there is some work for Odin to do. If I want to vendor my dependencies in C, all I have to do is place a header-file and DLL in my repository. I don’t even have to get into linking the source of projects together, heck, I can hand-write that header-file with only the code I need from the DLL.
Yes, I know about subtrees and submodules. Yes, I know about LFS. For the time-being subtrees are the best option for Odin. It’s essentially source-vendoring a package, and the ergonomics are OK since it’s an updatable-pull of another repo into a directory in your repo. It’s not rocket-science to push changes to the upstream codebase, and it doesn’t fuss with your repo metadata like submodules and LFS.
1 Like
Hey Bill, I’m just learning Odin and I’m probably a bit blind to the possibilities could you help me understand what you feel is the right way to distribute Odin code.
Do people who want to share code simply avoid using 3rd party code in their packages?
Is the idea to say that nesting inevitably causes shit-fuckery so just don’t do it?
Answering my own question.
I disagree about this being a git issue. There’s still projects that use other version control software out there, software that you might want to depend on. (not to mention other version control software might overtake Git in the future) (Moreover, game companies are especially prone to using non-git software for their closed-source stuff)
I’m aware other source-control exists. Do you have a more specific point?