[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: To all rock maintainers, take 3 (now with x64 supports)
- From: Sean Conner <sean@...>
- Date: Wed, 4 Nov 2015 15:00:52 -0500
It was thus said that the Great Stefano once stated:
> On 4 November 2015 at 04:42, Sean Conner <sean@conman.org> wrote:
> > Why do you still persist with the "contending module" errors?
>
> Short answer:
>
> I am working on ULua in my spare time among other projects.
> Moreover I disagree that the added benefit justifies the added complexity.
After some thought, I think I identified why this project doesn't sit well
with me---it's not curated. And because it's not curated, you provide a
random collection of Lua modules. Only it's not random, it *is*
deterministic but some are excluded just because they have a conflicting
module name who's project name sorts alphabetically prior to it (and for my
modules you have it listed under the completely *wrong* name because of how
you are treating module names).
You wrote:
> Unfortunately, a few rocks are not cooperative with 64 bit environments.
> I would thus be glad if you, rock maintainers, would be so kind as to
> assist by checking that your rocks are doing just fine.
But my modules don't have issues with 64-bit environments (heck, I'm running
on 64-bit Linux, 64-bit OS X and 64-bit SPARC) but they do have an issue
with names. And to me, I'm reading this as "please conform to my biases to
package management."
> Long answer:
>
> Right now the whole package manger stands at around 1K lines.
> And it's the first package manager I wrote, so probably it could be
> 25% smaller if I were to rewrite it.
> Other savings could be done by outsourcing some components (semantic
> versioning) or if Lua standard libraries were more extensive.
> There is no need for a package database, and packages are nicely
> organised in a package_name/package_version structure.
> The metadata for each package is stored in a single short Lua file.
> Nonetheless it supports multiple versions (loading the correct version
> of each required module), multiple os, multiple arch, live updates of
> the whole distribution, rollback in case of failures, updates, dynamic
> libraries pre-loading, executable Lua scripts. It's even fast.
>
> The feature you are requesting makes things way more complicated.
> This is just a small sample of the difficulties you will encounter,
> the devil is in the details:
> Need to distinguish between foo.bar of package foo instead of foo.bar
> of package foo.bar.
Why? Not not treat the module name as opaque? I did that for a project I
started back in 2014
(http://lua-users.org/lists/lua-l/2014-05/msg00656.html) that I should
probably pick up again. But anyway, I treated the module name as opaque,
with no structure. Here's the latest examle of LEM file (which is nothing
more than a ZIP file by the way):
[spc]lucy:~/projects/LEM>./zipf.lua sample.lem
The Eagle Has Landed
SunOS sparcv9 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.base64
SunOS sparcv9 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.crc
SunOS sparcv9 LGPL3+ Lua 5.1 5.1 5.1 MODULES/org.conman.env
SunOS sparcv9 LGPL3+ Lua 5.1 5.1 5.1 MODULES/org.conman.errno
SunOS sparcv9 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.fsys
SunOS sparcv9 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.hash
SunOS sparcv9 LGPL3+ Lua 5.1 5.1 1.1 MODULES/org.conman.iconv
SunOS sparcv9 LGPL3+ Lua 5.1 5.1 5.1 MODULES/org.conman.math
SunOS sparcv9 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.net
SunOS sparcv9 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.pollset
SunOS sparcv9 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.process
SunOS sparcv9 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.strcore
SunOS sparcv9 LGPL3+ Lua 5.1 5.1 1.0.0 MODULES/org.conman.sys
SunOS sparcv9 LGPL3+ Lua 5.1 5.1 5.1 MODULES/org.conman.syslog
Linux x86 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.base64
Linux x86 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.crc
Linux x86 LGPL3+ Lua 5.1 5.1 1.0.0 MODULES/org.conman.env
Linux x86 LGPL3+ Lua 5.1 5.1 1.0.0 MODULES/org.conman.errno
Linux x86 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.fsys
Linux x86 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.fsys.magic
Linux x86 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.hash
Linux x86 LGPL3+ Lua 5.1 5.1 1.1.1 MODULES/org.conman.iconv
Linux x86 LGPL3+ Lua 5.1 5.1 5.1 MODULES/org.conman.math
Linux x86 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.net
Linux x86 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.net.ipacl
Linux x86 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.pollset
Linux x86 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.process
Linux x86 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.strcore
Linux x86 LGPL3+ Lua 5.1 5.1 1.2.0 MODULES/org.conman.sys
Linux x86 LGPL3+ Lua 5.1 5.1 1.0.2 MODULES/org.conman.syslog
Linux x86 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.tcc
LGPL3+ Lua 5.1 5.1 MODULES/org.conman.cc
LGPL3+ Lua 5.1 5.1 MODULES/org.conman.date
LGPL3+ Lua 5.1 5.1 MODULES/org.conman.debug
LGPL3+ Lua 5.1 5.1 MODULES/org.conman.dns.resolv
LGPL3+ Lua 5.1 5.1 MODULES/org.conman.getopt
LGPL3+ Lua 5.1 5.1 MODULES/org.conman.string
LGPL3+ Lua 5.1 5.1 MODULES/org.conman.table
LGPL3+ Lua 5.1 5.1 MODULES/org.conman.unix
MIT Lua 5.1 5.1 0.10 MODULES/lpeg
MIT Lua 5.1 5.1 0.10 MODULES/re
Linux x86 MIT Lua 5.1 5.1 0.12 MODULES/lpeg
Linux x86 MIT Lua 5.2 5.2 0.12 MODULES/lpeg
MIT Lua 5.1 5.2 0.12 MODULES/re
Linux x86 MIT/X11 Lua 5.1 5.1 0.4.work3 MODULES/zlib
MIT/X11 Lua 5.1 5.1 2.0.2 MODULES/socket
Linux x86 MIT/X11 Lua 5.1 5.1 2.0.2 MODULES/socket.core
MIT/X11 Lua 5.1 5.1 2.0.2 MODULES/socket.ftp
MIT/X11 Lua 5.1 5.1 2.0.2 MODULES/socket.http
MIT/X11 Lua 5.1 5.1 2.0.2 MODULES/socket.smtp
MIT/X11 Lua 5.1 5.1 2.0.2 MODULES/socket.tp
MIT/X11 Lua 5.1 5.1 2.0.2 MODULES/socket.url
MIT/X11 Lua 5.1 5.1 1.0.1 MODULES/ltn12
FILES/APPNOTE.TXT
FILES/COPYING
FILES/README
FILES/Miscellaneous Things About Nothing
And to prove it's just a zip file (with a few extensions):
[spc]lucy:~/projects/LEM>unzip -l sample.lem
Archive: sample.lem
The Eagle Has Landed
Length Date Time Name
-------- ---- ---- ----
25472 05-24-14 17:10 MODULES/org.conman.base64
13448 05-24-14 17:10 MODULES/org.conman.crc
12200 05-24-14 17:10 MODULES/org.conman.env
18688 05-24-14 17:10 MODULES/org.conman.errno
57032 05-24-14 17:10 MODULES/org.conman.fsys
24952 05-24-14 17:10 MODULES/org.conman.hash
17664 05-24-14 17:10 MODULES/org.conman.iconv
17648 05-24-14 17:10 MODULES/org.conman.math
77944 05-24-14 17:10 MODULES/org.conman.net
26296 05-24-14 17:10 MODULES/org.conman.pollset
88256 05-24-14 17:10 MODULES/org.conman.process
37848 05-24-14 17:10 MODULES/org.conman.strcore
15392 05-24-14 17:10 MODULES/org.conman.sys
24312 05-24-14 17:10 MODULES/org.conman.syslog
14175 06-12-14 22:04 MODULES/org.conman.base64
8214 06-12-14 22:04 MODULES/org.conman.crc
7193 06-12-14 22:04 MODULES/org.conman.env
10690 06-12-14 22:04 MODULES/org.conman.errno
31885 06-12-14 22:04 MODULES/org.conman.fsys
15567 06-12-14 22:04 MODULES/org.conman.fsys.magic
14067 06-12-14 22:04 MODULES/org.conman.hash
10197 06-12-14 22:04 MODULES/org.conman.iconv
10816 06-12-14 22:04 MODULES/org.conman.math
43651 06-12-14 22:04 MODULES/org.conman.net
25248 04-18-14 20:06 MODULES/org.conman.net.ipacl
15914 06-12-14 22:04 MODULES/org.conman.pollset
49607 06-12-14 22:04 MODULES/org.conman.process
15666 06-12-14 22:04 MODULES/org.conman.strcore
9763 06-12-14 22:04 MODULES/org.conman.sys
13303 06-12-14 22:04 MODULES/org.conman.syslog
21218 06-12-14 22:04 MODULES/org.conman.tcc
5617 06-12-14 22:04 MODULES/org.conman.cc
2500 06-12-14 22:04 MODULES/org.conman.date
3829 06-12-14 22:04 MODULES/org.conman.debug
2966 06-12-14 22:04 MODULES/org.conman.dns.resolv
3260 06-12-14 22:04 MODULES/org.conman.getopt
2464 06-12-14 22:04 MODULES/org.conman.string
5243 06-12-14 22:04 MODULES/org.conman.table
2732 06-12-14 22:04 MODULES/org.conman.unix
40081 05-25-14 15:17 MODULES/lpeg
6029 05-24-14 00:36 MODULES/re
40045 05-28-14 15:24 MODULES/lpeg
40045 05-28-14 15:24 MODULES/lpeg
6286 05-28-14 15:24 MODULES/re
19794 05-30-14 21:29 MODULES/zlib
4451 05-28-14 14:52 MODULES/socket
55449 05-28-14 14:52 MODULES/socket.core
9243 05-28-14 14:52 MODULES/socket.ftp
12330 05-28-14 14:52 MODULES/socket.http
8074 05-28-14 14:52 MODULES/socket.smtp
3612 05-28-14 14:52 MODULES/socket.tp
11036 05-28-14 14:52 MODULES/socket.url
8331 05-28-14 14:52 MODULES/ltn12
161412 05-09-14 01:24 FILES/APPNOTE.TXT
The ZIP file format
7651 05-25-14 18:53 FILES/COPYING
9789 06-07-14 22:13 FILES/README
Much Ado About Nothing
3946 05-10-99 23:00 FILES/Miscellaneous Things About Nothing
If you this this has significance, think otherwise
-------- -------
1250541 57 files
While I could store both luuid's "uuid" and uuid's "uuid" modules in the
same LEM, I don't have a way to specify which one to use. That *is*
something I would need to work on. But as it stands, the LEM format can
easily handle different operating systems, different architectures and
different Lua versions (look closely---you'll see I have an LPeg 0.12 module
for Lua 5.1 and for Lua 5.2).
> Do we really have to follow Java's nested naming route here?
No. I could have use spc.net, spc.syslog, spc.signal, spc.errno, etc, but
I had the example of Java [1]. It may not be the best, but at least it's
*something*. One problem with Lua modules is that the name used to load the
module, say, require "uuid", doesn't necessarily match the name of the
project---there are three different UUID modules listed in LuaRocks:
luuid provides "uuid"
uuid provides "uuid"
org.conman.uuid provides "org.conman.uuid"
At the very least, my "project name" matches the "module" name.
This does make it hard for a package manager to provide the requested "uuid"
module (at least for the first two).
> Moreover, can I observe that we have a proliferation of incredibly
> small / badly maintained packages offering a quite limited
> functionality? Do we really need a separate rock for each single
> hashing function ?
The badly maintained I'll let slide, but small? That's a problem? And
yes, I wouldn't mind a separate rock for single hashing functions. Let me
load just what I need.
> And I am curious as to what you propose with respect to jason4lua and
> luajson, two modules who share:
> require 'json'
I propose to you---what would you do if someone would like to use package
manager to install json4lua? Or a different example---someone needs
numerical integration and thus, would like to use math-rungekutta but can't,
because it "conflicts" with math-evol.
Final parting words---if "conflicting modules" is too complex to handle,
then please, remove "org" from your project.
-spc
[1] The last Java project I worked on was in 1997. Yes, we do use Java
extensively at work, but the particular projec I work on uses C/C++
and Lua.
