Single file dependencies are amazing. I've never understood why it's so unpopular as a distribution model.
They can be a bit clunky in some languages (eg. C), but even then it's nothing compared to the dystopian level of nightmare fuel that is a lot of dependency systems (eg. Maven, Gradle, PIP). Free vendoring is a nice plus as well.
Lua does it right; happy to see some Fennel follow in that tradition.
Bratmon · 8h ago
The main reason you don't see it that often is because of the "what if some extremely common library that we depend on indirectly 63 times at a total of 11 different versions discovers that four of those versions have a major security vulnerability" problem.
For hobby projects, vulnerable dependencies are usually a minor annoyance that's often less annoying than dealing with more elaborate dependency systems.
For big professional projects, not being able to easily answer "are we currently running any libraries with major known vulnerabilities" makes this approach a non-starter.
fredrikholm · 5h ago
Cheers!
You mean in terms of having one centralized source of truth? I find this exact same problem with dependency systems as well; every project has their own dependency tracking file, and unless there is a deliberate attempt at uniting these into one trackable unit, you get this exact mess either way.
If the problem is automation (limiting human factors), then I'd say that whatever issue exists with single file dependencies is a tooling issue more than anything else. There's nothing about having one file that makes this any harder. In fact I'd say the opposite is true (eg. running checksums).
The one thing that dependency systems have going for them, is homogenized standardization. I'd rather go install x than whatever Ninja-generating-CMake-files-generating-Makefiles-that-generates-files-that-produce-a-final-file carnival rides that linger from the past. Perhaps its because of those scars that I like single dependency files even in / especially in larger projects.
whstl · 1h ago
I think this comment shows the difference between web development and other industries.
This problem is not existent in languages that traditionally use single-file libraries because projects rarely get to the point where they use 63 libraries, let alone have 63 indirect dependencies to a library.
Also: popular single-file libraries in the tradition of stb won't even have dependencies to other libraries of the sort, only to the standard library.
CyberDildonics · 1h ago
How would that be different if you have a source file split up into multiple files?
Having a list of what version you're using of a single file library seems like an easy problem to solve. If nothing else you could put the version number in the file name and in a debug build print off the file name.
whstl · 1h ago
I actually find them to be extremely popular in C and C++, and also in some Lua communities.
They just have an extremely vocal opposition.
This is not too dissimilar to static builds and unity builds, which also "make your life easier" but people will write tirades about how dangerous they are.
I wonder if C++ modules (which I'm loving) will also get the same treatment, since they make a lot of clunky tooling obsolete.
silvestrov · 3m ago
I think SQLite's amalgamation is one of the reasons SQLite is so popular for embedding.
CyberDildonics · 1h ago
I like to combine the two and put a lot of single file libraries into one compilation unit. It compiles fast and puts lots of dependencies in one place that doesn't need to be recompiled often.
They can be a bit clunky in some languages (eg. C), but even then it's nothing compared to the dystopian level of nightmare fuel that is a lot of dependency systems (eg. Maven, Gradle, PIP). Free vendoring is a nice plus as well.
Lua does it right; happy to see some Fennel follow in that tradition.
For hobby projects, vulnerable dependencies are usually a minor annoyance that's often less annoying than dealing with more elaborate dependency systems.
For big professional projects, not being able to easily answer "are we currently running any libraries with major known vulnerabilities" makes this approach a non-starter.
You mean in terms of having one centralized source of truth? I find this exact same problem with dependency systems as well; every project has their own dependency tracking file, and unless there is a deliberate attempt at uniting these into one trackable unit, you get this exact mess either way.
If the problem is automation (limiting human factors), then I'd say that whatever issue exists with single file dependencies is a tooling issue more than anything else. There's nothing about having one file that makes this any harder. In fact I'd say the opposite is true (eg. running checksums).
The one thing that dependency systems have going for them, is homogenized standardization. I'd rather go install x than whatever Ninja-generating-CMake-files-generating-Makefiles-that-generates-files-that-produce-a-final-file carnival rides that linger from the past. Perhaps its because of those scars that I like single dependency files even in / especially in larger projects.
This problem is not existent in languages that traditionally use single-file libraries because projects rarely get to the point where they use 63 libraries, let alone have 63 indirect dependencies to a library.
Also: popular single-file libraries in the tradition of stb won't even have dependencies to other libraries of the sort, only to the standard library.
Having a list of what version you're using of a single file library seems like an easy problem to solve. If nothing else you could put the version number in the file name and in a debug build print off the file name.
They just have an extremely vocal opposition.
This is not too dissimilar to static builds and unity builds, which also "make your life easier" but people will write tirades about how dangerous they are.
I wonder if C++ modules (which I'm loving) will also get the same treatment, since they make a lot of clunky tooling obsolete.
I thought it was the feature engineering company, Fennel, that was acquired by Databricks this year.