-
-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stop distributing LuaRocks stuff #964
Comments
alerque
added
todo
tooling
Build tooling, release management, and packaging processes
labels
Jul 20, 2020
@simoncozens If you can think of any objections to this, better speak up quick ;-) |
Do you mean "Stop" rather than "Step" in the title? I though it might be an extra "step" in the build process or something. |
alerque
changed the title
Step distributing LuaRocks stuff
Stop distributing LuaRocks stuff
Jul 20, 2020
@rjmunro Yes, I meant stop. 🛑 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I think our Lua Rocks distribution system has outlived its usefulness. New it's just causing trouble.
Current status:
When running
make dist
we fetch and build all the Lua Rocks we use for every supported Lua version (Now 4 versions) and stuff them in a directory (lua_modules_dist). When people build on a system--without-system-luarocks
the rocks for their version of Lua are extracted tolua_modules
, a directory which is then installed wholesale withmake install
.Rational:
This arrangement helped ease the transition from the original method of including the full source copied from these Lua modules as vendored code in our own repository, but now that other build methods are more refined it's becoming a millstone.
First of all, zero distributions use this stuff anyway: Arch, Ubuntu, Homebrew, Nix, Docker — so far every distro bar none with SILE packages has opted to use the system method, not the bundling method.
That leaves the use-case of end users doing a source install on their own. For their purposes I can't think of a good reason why they can't be bothered to fetch the rocks and build them using
luarocks
. Note this is not a convenience issue because the build script is still going to do it automatically for them either way, it will just use LuaRocks to fetch and build to the local tree at compile time instead of coping files out of the dist dir. On the flip side I can't think of a single scenario where a system might have a working Lua installation but not a working LuaRocks that we are actually helping. In fact the only situations I know of where this has happened are broken anyway because our provided luasocket/luasec doesn't match their distro's openssl version anyway, so they still have to work around that.Proposed status:
Stop bundling 4 versions of Lua modules source code and prebuilt rocks in our dist packages. Start assuming the make system can run luarocks to fetch and build those things better anyway in the event people want a "bundled" install that doesn't require and Lua rocks on their system (only
luarocks
the executable at build time).The text was updated successfully, but these errors were encountered: