Skip to content
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

Closed
alerque opened this issue Jul 20, 2020 · 3 comments · Fixed by #965
Closed

Stop distributing LuaRocks stuff #964

alerque opened this issue Jul 20, 2020 · 3 comments · Fixed by #965
Labels
todo tooling Build tooling, release management, and packaging processes
Milestone

Comments

@alerque
Copy link
Member

alerque commented Jul 20, 2020

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 to lua_modules, a directory which is then installed wholesale with make 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).

@alerque alerque added todo tooling Build tooling, release management, and packaging processes labels Jul 20, 2020
@alerque alerque added this to the v0.10.9 milestone Jul 20, 2020
@alerque
Copy link
Member Author

alerque commented Jul 20, 2020

@simoncozens If you can think of any objections to this, better speak up quick ;-)

@rjmunro
Copy link
Contributor

rjmunro commented Jul 20, 2020

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 alerque changed the title Step distributing LuaRocks stuff Stop distributing LuaRocks stuff Jul 20, 2020
@alerque
Copy link
Member Author

alerque commented 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
Labels
todo tooling Build tooling, release management, and packaging processes
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants