Closed leidegre closed 11 months ago
I appreciate what you're trying to do, but I don't want to put a package manager in this build system. It seems to me you could get 99% of what you're trying to here with a pre-processing tool that would load the build scripts and run the checkouts as needed, perhaps making additional source list files. That way there's less stuff that can break in Tundra itself.
Yeah, no I get that. No worries.
I think I was just looking for a place to talk about this. Hoping that additional people might find it useful or interesting.
I think it's an interesting idea, but yeah, it comes with lots of issues.
I think I'll revisit this in the future. See what can be done. I'll ping you guys on Twitter if/when I have something to share.
Right now I just build all my external dependencies by putting the source in a folder and writing a unit for it.
For example, to use zlib:
<workspace>/vendor/zlib-1.2.13
StaticLibrary
unit"zlib"
tounits-vendor.lua
zlib
when I want to use zlib.But what if I could do this?
As part of the build or as part of some package manager:
<workspace>/t2-packages/zlib
<workspace>/t2-packages/zlib/zlib.lua
tounits-packages.lua
(and maybe remap some names)And you should be to build it like so:
Stuff like this is like opening the biggest can of worms ever! but there are some good ideas out there on what to do and what not to do. I'm really impressed by what the Go authors did in this space and I think they had many good ideas.
If there's any interests in this from the community I would like to try and hash out some kind of spec for how you could package and share code that will be built with Tundra. For example, it is unlikely that the zlib GitHub repo will contain a units.lua file but one could be provided from a repository if there was a simple package manifest format that could combine source location and Tundra unit definitions. I don't suggest hosting a repository but maybe we could dedicate a github repo for this purpose.
This way, looking up a package is simply a fetch from this github repo which may reside on github.com or locally (i.e. it's just a local file system). Installing "zlib" is just looking up the name "zlib.json" in this repo. Here's an example of a package manifest JSON:
"source"
could be changed to something like:In which case you just symlink this path into something like a
<workspace>/t2-packages/zlib
.I don't want to go crazy with this but what I want to do is to spread tundra and make it more valuable for people to adopt. And I strongly believe in keeping things simple. To me, a Tundra package is ideally just a way for me to obtain the source and some unit definitions that I can then reuse in my Tundra projects. Not all projects in the world wide web will lend itself to this approach and I think that's fine. I also think it might be possible to do this without changing a single line of Tundra source code. Maybe add a special unit type for some name remapping/namespace feature but that's it.
If the interest in something like this is low I will close this issue otherwise I might make a few experiments and see what sticks.