Configuration

[pablomayobre]

It has been discussed that we should move away from using conf.lua possible in version 3 ( #40 ) and that this would help on moving to a Lua version agnostic ( #46 ) system.

To do this we need to define a new format for the configuration, so I decided to open this issue only to discuss how this format should be. I propose this package.lua file format:

local release = require 'plugin.loverelease'
local commands = {}

function commands.build ()
  release.cacheDirectory('cache')

  local metadata = {
    name = 'Test game'
    version = '0.0.1'
    description = 'A test game for love-release',
    author = 'Positive07',
    email = 'pablo.a.mayobre@gmail.com',
    url = 'https://github.com/Positive07/test',
  }

  local love = release.newLove {
    src = '.',
    include = {},
    exclude = {'.gitignore', 'package.lua', 'README.md'},
  }

  local icons = release.getIcons {
    '32' = 'icon32.png'
  }

  local mac = release.newMacOSX {
    file = love,
    meta = metadata,
    icon = icons.icns,
  }

  local win32 = release.newWindows {
    file = love,
    meta = metadata,
    icon = icons.ico,
    arch = 32,
  }

  local win64 = win32:fork {
    arch = 64
  }

  release.output 'build' {
    ['game-windows-32'] = win32,
    ['game-windows-64'] = win64,
    ['game-love'] = love,
    ['game-mac'] = mac
  }
end

return commands

So this file returns a list of commands, this commands can be executed by running them like so:

love-release build

When the file runs, the release plugin is loaded with require from an specific plugin directory of love-release. This plugin exposes some common operations like newLove, newWindows and newMacOSX, please note that this don't really create files, but configure tasks.

The tasks are executed with release.output which first takes the directory and returns a reusable function, that when called with a table with tasks as values performs all the tasks and saves the resulting files in the specified directory with a name corresponding to their index. This functions is synchronous and may take it's time, so that is something to keep in mind.

Most tasks take a love task, this is so that the generated LÖVE (.love) file can be reused, but reusing a file is not required.

Lastly I want to note that all the tasks have a branch method that allows you to create a new task with all the same configurations as the task you are branching from and change only the specified configurations.

This is my proposal, please give it a thumbs up 👍 if you are in favor or discuss any changes you would like to make. I would like to see different proposals too, to spark more ideas on this kind of stuff!

[pablomayobre]

I also want to add that this opens up some really cool possibilities, for example I used an operation called getIcons which takes png images of different sizes and generates ico, icns files and any other necessary file on request.

There could be release.lint command which uses luacheck internally, or release.test to run busted tests.

There could be newAndroid, newDebian, newAppImage, newRPM, newArch, etc.

There could be a task to download and bundle loverocks libraries. and so on (maybe it's own plugin). This format makes configuration easier while giving a huge set of options to the user.

And since the format is not static you could for example bundle some assets for Windows and MacOSX while packaging different ones for Android (useful for example with compressed textures), you could abort the build if the tests and the linter fail. You could update the version string automatically by detecting the current tag of Git somehow... This package.lua is extensible and you could use plugins for this script...

I'm thinking that this may be a project on it's own...

[MisterDA]

It is a very, very, very good proposal! I'll have plenty of time this summer to work on love-release and I'd be glad to work on your proposal, but if you'd like to do it your way first, well I'll happily accept your work and switch love-release to the new implementation :)

[pablomayobre]

I would love to work together with you if we go this way 😄. I'm not really interested in having MANY similar packages, and there are a bunch of projects trying to do similar stuff already so I prefere to help here like you may have noticed hahaha.

PS: If you are on Discord I'm Positive07@8080 PM me if you want, I'm in touch with @rm-code over there (I think he was interested in this project too)

[pablomayobre]

I have updated the issue and first comment to reflect on the possibility of plugins

[TangentFoxy]

While I like the idea of this being available for more advanced usage, I really like how simple it currently is to use love-release with just minor modifications to conf.lua. I would hope that backwards compatibility is kept and/or a simpler version of this is kept.

[pablomayobre]

If this was ever implemented, a default would be given, and that default would require conf and get the configuration from there yeah.

Also it has been long but I have already finished Obey which is the tool that could potentially power this. Yet the plugin for love-release was never written so maybe this can spark some new interest in it.

[TangentFoxy]

It also just occurred to me that the conf file has to register a function for it to work with love, but it doesn't return anything special, so you could also use a return value if configuration is kept in the same file.

I don't particularly see a need to separate it into another file, but I understand why it would be a good idea. I'm curious if anyone here has an example of a conf file that demonstrates why it should be moved away..

[pablomayobre]

This has already been discussed A LOT, and the final decision is that usingconf.lua is generally not a good idea, lot of stuff other than just defining love.conf can happen in this file, and love-release will fail to load it appropriately.

Also since LÖVE 0.9.x there is almost no need for metadata to exist in conf.lua (author and version are deprecated, only identity and LÖVE version are useful)

There is a lot of stuff to configure for love-release so it's a good idea to have a better way to define all this configurations and script it as you would do with a build pipeline.

For more info read #27 #40 #46

About what you ask, it has been said over and over that there will be a fallback to conf.lua, and that's also one of the reasons Obey is a separate project. The idea is that Obey would use love-release (and possibly loverocks) as a plugin, while you can still use love-release (and loverocks) standalone, which would use conf.lua or CLI arguments.

Let's keep this issue related to the new configuration file and how to integrate love-release into Obey (or the other way around)