Page MenuHomeFreeBSD

devel/lua-luarocks: update to LuaRocks 3.0.0
ClosedPublic

Authored by russ.haley_gmail.com on Jul 15 2018, 4:21 AM.
Tags
  • Restricted Project
Referenced Files
F80137430: D16274.id.diff
Thu, Mar 28, 10:42 AM
Unknown Object (File)
Feb 22 2024, 7:49 AM
Unknown Object (File)
Feb 14 2024, 6:59 AM
Unknown Object (File)
Feb 14 2024, 6:59 AM
Unknown Object (File)
Feb 14 2024, 6:59 AM
Unknown Object (File)
Feb 14 2024, 6:59 AM
Unknown Object (File)
Feb 14 2024, 6:59 AM
Unknown Object (File)
Feb 14 2024, 6:59 AM
Subscribers

Details

Summary

New Lua package manager that supports more features and per directory installation. The following is the list announcement from Hisam:

Hello list,

I am happy to announce LuaRocks 3.0.0, the new major release of
LuaRocks, the Lua package manager>

It includes a lot of new stuff, as previewed in the beta and rc pre-releases:

  • New rockspec format
  • New commands, including luarocks init for per-project workflows [1]
  • New flags, including --lua-dir and --lua-version for using

multiple Lua installs with a single LuaRocks

  • New build system, gearing towards a new distribution model [2]
  • General improvements, including namespaces [3]
  • User-visible changes, including some breaking changes
  • Internal changes

All of the above are detailed here:

The LuaRocks wiki still needs to be updated to cover most of the new
features (it would be odd to have the documentation up when the
features weren't released yet). Any help updating the wiki is
especially welcome!

Files for Unix and Windows are here:

https://luarocks.github.io/luarocks/releases

This release contains both the Unix tarball and two versions of the
Windows zip: the "legacy" installer which works the same as the zip
files released with all LuaRocks versions so far, and a new zip file
with the all-in-one luarocks.exe binary that runs with no additional
dependencies. The luarocks.exe program assumes you're using a
Microsoft compiler toolchain when running from the Visual Studio
developer console, or a mingw toolchain otherwise (everything can be
hand-tuned via config files as usual).

This release contains new code by Thijs Schreijer, George Roman, Peter
Melnichenko, Kim Alvefur, Alec Larson, Evgeny Shulgin, Michal Cichra,
Daniel Hahler, and myself. The LuaRocks.org server is maintained by
Leaf Corcoran.

Once again, very special thanks to my employer Kong, for sponsoring my
work on LuaRocks over the last year and making this release possible.
Special thanks also to François Perrad and Matthew Wild for their
feedback during the beta and rc phase.

LuaRocks is what it is today because of its community, that
continuously releases new rocks in https://luarocks.org and makes the
Lua ecosystem all the more useful — keep on rockin'!

Come chat with us at https://gitter.im/luarocks/luarocks
and please report any issues at https://github.com/luarocks/luarocks

3.0.0 cheers for the new release!

Hisham Muhammad

[1] https://github.com/luarocks/luarocks/wiki/Project:-LuaRocks-per-project-workflow
[2] https://github.com/luarocks/luarocks/wiki/Project:-LuaRocks-new-distribution-model
[3] https://github.com/luarocks/luarocks/wiki/Namespaces

Test Plan

Test against new 5.3 and 5.4 ports in D13690 and D14609.

2018-07-23:

  • As per note in summary, make needs to be run twice.
  • Testing is ongoing due to poor mistakes on my part. I was accidentally testing against beta2. Beta 2 had no problem downloading and building rocks, but the package.paths are not correct for use with the local modules. Will continue testing.

2018-07-29:

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

There seems to be a bug in the base LuaRocks Makefile that requires running 'make build' twice. Therefore this patch works if you run make twice. I have a message on the Lua mailing list for further information from Hisham.

Makefile
2–3
DISTVERSION=  3.0.0beta2
26–27

This does not do what you think it does. Remove the commented out line.

38–41

If those targets are now empty, please remove them.

Cleanup. Added port revision number.

Makefile
2–3

This is in the wrong order. Also, use DISTVERSION=3.0.0beta2.

linimon retitled this revision from LuaRocks 3.0.0 Beta2 to devel/lua-luarocks: update to LuaRocks 3.0.0 Beta2.Jul 18 2018, 12:47 PM
russ.haley_gmail.com retitled this revision from devel/lua-luarocks: update to LuaRocks 3.0.0 Beta2 to devel/lua-luarocks: update to LuaRocks 3.0.0.
russ.haley_gmail.com edited the summary of this revision. (Show Details)
russ.haley_gmail.com edited the test plan for this revision. (Show Details)
  • Updated as per comments. Thanks @mat.
  • LuaRocks has been released. Updated port to release download.
russ.haley_gmail.com edited the summary of this revision. (Show Details)

Whitespace alignment. It looks great in geany...

Doesn't build for me. Trying to figure out why.

Looks like a missing USES+=gmake

(The makefile expects $(CURDIR) to be set, which is a GNU-make-ism)

No, seems there's lots more wrong with this - at least the install is broken (looks like it's not respecting the staging dir)

Please revert all the whitespace changes, it is impossible to read the diff with all the noise.

Makefile
38–41

Those targets are empty, please remove them.

In D16274#348497, @mat wrote:

Please revert all the whitespace changes, it is impossible to read the diff with all the noise.

Sorry, a complete mistake. I'll revert tonight.

Changes:

  • Rebase against current existing port rather than previous version.
  • Add USES+=gmake
  • Add Makefile patches to respect $(DESTDIR) so that make stage works.
  • Fix an upstream bug.
  • Regenerate pkg-plist to match new version's files.
kevans added inline comments.
Makefile
3

This should be reverted to the previous USE_GITHUB=yes; the GH_ACCOUNT and GH_PROJECT defaults are good here now [1]

[1] https://github.com/luarocks/luarocks

27

There is no previous value for USES, this should probably be USES=

files/patch-Makefile
22 ↗(On Diff #45796)

For these targets (including the vanilla install: target), it's usually preferable to use proper INSTALL_* macros rather than cp/echo + chmod

files/patch-Makefile
22 ↗(On Diff #45796)

Yeah, but fixing that kind of thing would mean rewriting half the makefile, which I think is better addressed upstream (I've already mentioned it to them). My objective was to make it work within the existing structure of the makefile.

Makefile
3

It looks like the direct github download contains a bunch of useless-to-us windows DLLs that really bloats the file; 5 meg rather than 200k.

Makefile
3

I'll defer to @mat or any other ports person on that... I don't know if the space savings outweighs the benefit of, e.g. the multiple MASTER_SITES that come along with USE_GITHUB.

Makefile
3

There are no multiple MASTER_SITES when using USE_GITHUB, so not sure what you are talking about.

Our policy is to always use the official distribution file provided by the projects if they are available.

27
Makefile
3

Clearly misremembering- for some reason I thought there was more than just https://codeload.github.com

Makefile
3

Is there any policy on preferring https to http?

Makefile
3

Until the end of 8.3 (or maybe 8.4) support, we needed http master sites because fetch's proxy feature did not include https support.
Nowadays, irrelevant.
If http and https are served by the same server, use https. Also, try not to use a URL that redirects to some other URL.

Style/format fixes

Also remove redundant --versioned-rocks-dir option

russ.haley_gmail.com edited the test plan for this revision. (Show Details)

Style/format fixes

Also remove redundant --versioned-rocks-dir option

Thanks @andrew_tao173.riddles.org.uk. This works for me on amd64 11-2. Will test on arm asap

I'm told there's a 3.0.1 release likely within a week or so that fixes both the bug and the build process issues discussed here.

Update to 3.0.1.

This one still has a makefile patch (actually GNUmakefile now) to make the install respect our INSTALL_SCRIPT and INSTALL_DATA, but it's not as intrusive as before.

It would be nice to make it install config-*.sample for all of the supported lua versions, but I don't see a good way to do that (other than making a bunch of assumptions about the file content and using sed scripts).

This revision was not accepted when it landed; it landed in state Needs Review.Aug 16 2018, 4:53 PM
This revision was automatically updated to reflect the committed changes.
Makefile
38–39

Mk/bsd.port.mk has still cruft left after staging support was added. ${INSTALL_*} commands try to enforce user/group and permissions but non-default values are no longer recommended after CHANGES@20140922. As INSTALL_AS_USER isn't set by default the installed files will be always owned by root/wheel while permissions are subject to the default umask (i.e., 022). So, the only real change here is the removal of write permission for owner. Given the vast majority of ports don't do this I'm not sure what's the benefit given the maintenance cost.

files/patch-GNUmakefile
9 ↗(On Diff #46687)

The correct way to create new directories is install -d (not mkdir -p) as it allows to set user/group and permissions. Otherwise, no need to be pedantic trying to chase every variable the ports framework uses at the expense of maintenance cost.

files/patch-src_luarocks_cfg.lua
1

The file was renamed, not removed upstream. Respecting CC/CFLAGS/LD/LDFLAGS is mandatory in ports/ i.e., if this port is ever used in BUILD_DEPENDS. DragonFly support is a bonus but highlights platform whitelists that often grow out of date.

pkg-plist
1 ↗(On Diff #46687)

Having version-specific shebang or installing under versioned directories (i.e., supporting only specific version) requires versioning the binaries as well to avoid pointless package conflicts.

It would be nice to make it install config-*.sample for all of the
supported lua versions, but I don't see a good way to do that (other
than making a bunch of assumptions about the file content and using
sed scripts).

May not be a bad idea. LUAJIT option already has some assumptions. However, if unversioned package is desired then PKGNAMEPREFIX should be dropped and devel/lua-luarocks renamed to devel/luarocks. For consumers it'd mean not specifying flavor as required lua version to build may not match version luarocks depends on.

To avoid blocking progress on Lua improvements in ports in future I've dropped maintainership in rP477379.

devel/lua-luarocks was originally created to help me port Torch7, using waifu2x (the original implementation, written in Lua) as a goal. That effort has stalled (see lua-sundown and lua-trepl for examples how to use lua-luarocks as BUILD_DEPENDS) due to Torch7 only really supporting LuaJit and overall effort required to port more libraries than just Torch7, some of which had CUDA dependency. LuaJit support for lua- ports was suboptimal at the time and depending on non-default Lua version meant creating many slave ports. So, I gave up.

files/patch-src_luarocks_cfg.lua
1

Actually, respecting CC/CFLAGS/LD/LDFLAGS can be via command-line arguments e.g., luarocks-5.2 build --local CFLAGS="-O3 -pipe -flto -fPIC" LIBFLAG="-flto -fuse-ld=lld -shared" penlight. If this is done in USES=luarocks, USE_LUA=luarocks or similar the patch can go away. However, other language-specific package managers usually respect user environment (e.g., devel/py-pip, cargo from lang/rust).