Proposals for love-release 3

[MisterDA]

Hello everyone!

It's been a little over three years since I began developing love-release. It allowed me to meet awesome people (mostly Lua developers) from all over the world, and talk with a lot of people online. It's really fantastic and I'd like to thank all those who helped me with love-release.

I started love-release in high school, and now that I have some college behind me, I'd like to see a little more to love-release. Especially now that there are much more tools that accomplish more or less the same thing... I'm listing below the most advanced tools.

• Ulydev's LÖVE-Packer, he's currently rewriting it but it will certainly be a complete tool,
• unek's LÖVE Executor (lover.unek.xyz), a website that creates Windows exe of LÖVE projects, with many configuration options,
• qubodup's LoveToAndroid, a Windows tool to make Android's .apk from LÖVE projects,
• JanWerder's LoveAutoComp, a continuous packaging application.

Meanwhile, I use Java for courses and Java has a long history of build tools (Ant, Maven, Gradle), and I've used them for my Java projects. I think they really help the development process. I'd like to have a build tool for LÖVE projects.

What would it do? What features would it have ?

I have written a lot of the ideas I have. I'd like new ideas, suggestions, and feedback from you for now. Feel free to talk about everything here, or to create new issues to talk about specific ideas.

Using love-release

Some of the new tools are web applications that run on private servers. I won't do that and I prefer to use a Lua script, conveniently installed on my computer. I also means that love-release will probably have to download and compile some stuff for Android / iOS and other LÖVE ports.

I'm still planning on using Lua and LuaRocks. love-release will be installed through LuaRocks. LuaRocks has some great APIs, particularly luarocks.fs and luarocks.dir that provides a good abstraction layer over luafilesystem, luaposix, and luasec. You can download files and do filesystem operations in a very convenient and portable way.

love-release will still be used as a command-line script, but who knows? with time a graphical front-end could appear.

Tasks

I'd like love-release to be closer to a build tool. Build tools such as Gradle or Maven work with tasks, Make calls them targets. Examples of what tasks could look like:

• run - Runs this project
• assemble - Assembles the outputs of this project.
• build - Assembles and tests this project.
• clean - Deletes the build directory.
• love - Assembles an LÖVE archive.
• distWin - Bundles the project as a Windows distribution.
• distOSX - Bundles the project as a Mac OS X distribution.
• ldoc - Generates LDoc API documentation for the main source code.
• check - Runs all checks.
• test - Runs the unit tests.

We could benefit of the Lua ecosystem by integrating ldoc support for documentation, luacheck for static code analysis (checks), and busted or telescope for testing.

Configuration

As discussed in #27, love-release should not store its configuration in LÖVE's conf.lua file, but rather in its own love-release.lua configuration file (the name is a proposal). The shape of this file will depend on how I develop love-release internals, but aside from the configuration, it could also be used to extend love-release tasks and functionalities.

Include / Exclude files

As discussed in #39, love-release should be able to properly include and exclude files. I think the default behavior of keeping a LÖVE file and syncing it with the filesystem is good.

Distribution

Support all the platforms!

As of 0.10.1, LÖVE supports Windows, Mac OS X, Linux, Android and iOS. It's a long process to release a game for each of these platforms, and that's why I've created love-release in the first place. The main goal of this tool should be to automate this process.

While every platform can use the same LÖVE file, they do differ in the distribution process and there are also small enhancements that are specific to each platform, such as icons, ads, app-signing...

love-release could also support LÖVE unofficial ports. I'm mostly thinking of Tanner's Love.js port.

Global

Every platform requires some information about a LÖVE project:

• the name (can be deduced from the project's directory name)
• the package name (if your project is called MyAwesomeGame you would expect something like my-awesome-game)
• the LÖVE version this game was made for

Other information, while optional, are shared by many platforms:

• the game version
• a copyright statement
• a company/author name
• a company identifier/url
• a description

LÖVE file / Windows / OS X

Not much new with Windows nor OS X. There are still improvements to make, like the support of icons.

Android / iOS

Support for Android and iOS will be achieved with LÖVE 0.10 official ports to theses platforms. I don't really know how I'll handle that yet, but it will come.

GNU/Linux

I'd really like to add a better support for GNU/Linux. For now, you have two options:

• using a *.love file and telling the user to install LÖVE,
• using a Debian package (.deb) which automatically pulls LÖVE as a dependency.

funkeh's LÖVE Linux Distribution could be used with conjunction of:

• Gnome sandboxed app project flatpak,
• Ubuntu Snap packages.

Projects & subprojects

If you create a game using libGDX you have a core subproject and other subprojects for every platform you intend to release your game on. Windows and Android might share the same logic while having different UIs and event-handling schemes.

Package management

Lua's package manager is LuaRocks.

Most of the libraries people have written in/for LÖVE or in pure Lua are hosted there. There is a dedicated manifest that acts like a tag on LuaRocks website to find packages coded for LÖVE.

I believe that a package manager for LÖVE projects would be a great thing. You would just add a lib and a version of this lib in a file, and your project will use the lib accordingly. A big plus for automatic updates, dependencies, bug fixes and so on. Most of the libs are pure Lua. Libs written in C could cause more trouble.

Alloyed has started a project, loverocks, that can fetch libraries from LuaRocks and load them for LÖVE projects, but not yet package them. This could be a starting point. I would really like to provide developers a good way to ship their games dependencies easily. It also means that dependencies licenses should probably be shipped with the game.

As a side note, I strongly encourage library writers to put their work on LuaRocks. It's simple and efficient (docs).

Compilation

While not necessary, the code of a LÖVE project can be compiled to LuaJIT's bytecode. As stated somewhere in the forum it decreases a little the boot time (but does not obfuscate or "hide" the code in any way -> licensing is the only viable option).

LÖVE conf.lua / versions

The conf.lua file gives a lot of information about a LÖVE project. Alloyed's loadconf is currently used by love-release to load the file, but as discussed in #27, love-release should not load this file and should have its own configuration file.

I think that I'll keep the loadconf functionality as a fallback mode if love-release's configuration file is not found.

Old versions of LÖVE should still be supported too. I don't know if there is a library providing a compatibility layer between different versions, but if so the library could be automatically used.

Zip backend

love-release uses brimworks/lua-zip, a binding to the widely-used C library libzip.

Using libzip means that it must be compiled on the host machine, which is not always a trivial task on Windows and not something a new user would like to do. I also had some problems using the Homebrew package on OSX.

lua-zip needs to be freshened a little, as its author seems not very responsive I'll create a fork to integrate the most recent changes from the network and I'll add some stuff on my own to enable Lua > 5.1. Besides, the binding is not complete and lacks some of the C functions.

I can also switch to another backend. LuaRocks has its own API to deal with zip files, but I think it's not as complete as lua-zip.

Bonus

Static

luastatic could be used to build a standalone executable of love-release to use a standard app, removing the need of LuaRocks and the installation of libzip.

IDE integration

Zerobrane Studio, Atom, Vim plugins?

Filesystem watcher

Any need to watch the filesystem for changes? Alloyed's love-watch does the job for Linux.

Bugs fixes

Yeah.

[Alloyed]

Good morning! Integration between love-release and loverocks sounds pretty good to me.
I split off a few issues for things I could reasonably contribute to:

Loverocks by design installs all of its libraries into a folder you can just ship with your game, rocks/. This is already good enough if you only use pure lua code. Native C code is harder and needs more integration with a build tool, #41 covers my thoughts I think.

Alloyed/loverocks#7 covers turning the code in loverocks into a library you can just use on its own. If you have something specific in mind that you want in terms of API design/things you might want to do with rocks packages, feel free to ask.

[JanWerder]

Hey,

I'll be honest, I never got love-release to work, but that's entirely not your fault. Last time I tried Windows refused to work properly with luarocks, which was a mess on Windows back then. I would like to try it again though.

With that being said, you are tackling some of the hard problems in your post, but some of them are non-issues to me.

Package management has a always been an unsolved problem for me in Löve, which is partly why I created https://github.com/love2d-community/awesome-love2d to keep track of most libraries at least somehow. Subprojects were nothing I ever came in contact with, so I can't really comment on them. The rest you described seem to be love-release specific problems.

Supporting all platforms is the huge problem, at least to me. Currently there is just no tool that can easily deploy to every platform out there. It's not Löve's fault, since this part of the whole SDK mess of the mobile platform. In that regard. I will keep an eye on love-release and I hope you can solve that with your script.

With that being said, I wish you the best of luck solving the problems you described on your roadmap!

[pablomayobre]

I would totally prefere a standalone (luastatic) in order to drop Luarocks and so that users don't need to compile luazip which is a bother.

Also we could do something like npm where if you try to npm install it won't do anything if a project doesn't have a package.json, but you can use npm init in order to create this file, npm init will take information from different places and ask for missing pieces of information in order to generate a complete package.json.

We could have love-release init which would use loadconf in order to parse the conf.lua file to find, author name, game name, package name, etc. If not found, the user can fill the missing fields in order to generate the configuration file love-release-conf.lua or whatever.

[pablomayobre]

Regarding @TannerRogalsky love.js port, the newest 0.11 version has a CLI tool that compiles any LÖVE game into a web page! I think it would be great to integrate with this new tool

[TannerRogalsky]

The tooling around building a love.js page isn't very complicated and could be converted to Lua. It requires some binary file IO and rendering some HTML/JS templates but that's about it.

[pablomayobre]

That would be even better! Can you point me to the JS code that is currently handling those build steps?

[TannerRogalsky]

Totally. https://github.com/TannerRogalsky/love.js/blob/0.11/index.js

[TannerRogalsky]

One weird thing about that code is that I use different methods/file structure for it's passed a folder or a .love game. love-release should only have to worry about working with a .love game anyway so that should be a little simpler.

[pablomayobre]

Should debug and release distributions be separate things?

[TannerRogalsky]

I'm considering removing the debug build. It's really big and not particularly useful to end users. But, to answer your question, yeah, they should be separate things.