Re: Packageing a Lua module (or: lcurses for 5.3)

[Hisham <h@...>]

On 10 January 2015 at 13:44, Luiz Henrique de Figueiredo
<lhf@tecgraf.puc-rio.br> wrote:
>> Luiz, for example, doesn't even use version numbers for his modules!
>> No offense intended, but that's far from being a Holy Grail of best
>> practices.
>
> No offense taken. Is not having version numbers really that bad?
>
> My modules do include date information inside and that is enough
> for me to know which version is being used in case an issue arises.
>
> More importantly, my modules are really stable and so what other
> purpose would version numbers serve?
>
> I'm not being (too) defensive. I'm just curious whether not having
> version numbers is really a hindrance to someone.

We usually get around the lack of version numbers by using the release
dates as version numbers, but it can get a little confusing at times.

Given that there are separate tarballs (effectively separate releases)
for 5.1 and 5.2 versions of the modules, sometimes they get different
release dates and sometimes they don't. I was using the separate dates
to my advantage when packing rockspecs (version 20130502 would say
"5.1 only" in its dependency and version 20130507 would say "5.2
only"), but then some pairs were released the same day, and I ended up
inventing version names such as 20130708.51 and 20130708.52 to
circumvent that (don't know how other packagers, eg, Debian, solve
it). Note that this can be seen as a limitation of LuaRocks, since we
don't have a feature to say in a single rockspec "for Lua 5.1 grab
from this URL, for 5.2 grab from that URL", but as we understand a
given version refers to a given piece of code.

Another unusual aspect of your setup is that old versions disappear
from the server, overwritten by new versions. The modules are pretty
stable but every now and then a new version of a module (for the same
Lua version) comes up. If we didn't have md5 check in the rockspec,
the rockspec would start to silently grab the latest one, reporting
the wrong version in `luarocks list` and causing all sorts of
confusion. With the md5 check, the rockspec breaks (which is better).
To overcome this breakage, we store .src.rock files in the server,
which bundles the original tarball. So we keep your old versions
around in our server, and nothing breaks. But it's nicer for
maintenance (and verifiability) if URLs for releases are stable,
that's why downstream prefers if projects pack as foo-1.2.3.tar.gz
instead of foo.tar.gz.

So no, it's nothing super serious but it takes some working around, so
I'd prefer to point people to more "standard"/widespread practices for
packaging. :)

I do like the release.txt file though, and at one point I even wrote a
personal script called lhf-updater that scans that file and generates
new rocks. :)

-- Hisham