Re: To all rock maintainers, take 3 (now with x64 supports)

[Sean Conner <sean@...>]

It was thus said that the Great Stefano once stated:
> On 5 Nov 2015 01:56, "Sean Conner" <sean@conman.org> wrote:
> >
> > It was thus said that the Great Stefano once stated:
> > > On 4 November 2015 at 20:00, Sean Conner <sean@conman.org> wrote:
> > > >


> Also, I do not face those same problems. Indeed my code, publicly
> available, deals with all the mentioned issues in a trivial way (of
> course, also thanks to the design choices which you don't seem to like).

  The only design choice I don't like is how you designate a "module".  

> > > I welcome your ides on how to handle it. Not in the sense of storing
> > > them in a package. I am talking about the package management logic
> > > here.
> >
> >   Treat the module names as an opaque string and stop trying to shoehorn
> > everything into what appears to be a top-level module.  Lua does this
> > internally (after require "org.conman.table", require "pl", require
> > "socket"):
> >
> > > show(package.loaded)
> > string            table: 0x9acb618
> > org.conman.table  table: 0x9add188
> > package           table: 0x9acba50
> > _G                table: 0x9aca450
> > os                table: 0x9acd3c8
> > table             table: 0x9acb100
> > math              table: 0x9acdf90
> > coroutine         table: 0x9acb718
> > pl.utils          table: 0x9ae3328
> > debug             table: 0x9ace990
> > pl                true
> > io                table: 0x9accbc0
> > socket.core       table: 0x9aeea48
> > pl.import_into    function: 0x9ae29b0
> > socket            table: 0x9aeea48
> > org.conman.net    table: 0x9ae3a28
> > pl.compat         table: 0x9ae9718
> >
> >   Just because "org.conman.table" is stored on disk as
> > "org/conman/table.lua" doesn't necessarily mean "org" is the top level
> > module here.  It's "org.conman.table".  Yes, this might complicate your
> > package manager some, but I was able to deal with a ZIP file with
> > duplicate filenames!
> 
> The point of contention is that 'some'.
> 
> If it is so trivial, you would really do me a great favor by contributing a
> patch that solve this contentious point once and for all.

  As far as I can see, there is no code out there that actually *generates*
the PKG files that are downloaded.  That is where the change needs to
happen, in the actual packaging of the Lua modules.  Currently, I see this
structure:

org
org/1_0_1+3
org/1_0_1+3/__meta.lua
org/1_0_1+3/Linux
org/1_0_1+3/Linux/x64
org/1_0_1+3/Linux/x64/-org_conman_env.so
org/1_0_1+3/Linux/x86
org/1_0_1+3/Linux/x86/-org_conman_env.so
org/1_0_1+3/OSX
org/1_0_1+3/OSX/x64
org/1_0_1+3/OSX/x64/-org_conman_env.so
org/1_0_1+3/OSX/x86
org/1_0_1+3/OSX/x86/-org_conman_env.so
org/1_0_1+3/Windows
org/1_0_1+3/Windows/x64
org/1_0_1+3/Windows/x64/-org_conman_env.dll
org/1_0_1+3/Windows/x86
org/1_0_1+3/Windows/x86/-org_conman_env.dll

  Your problem is assuming that "org" is the name of my module---it isn't
(and no, I'm not being sarcastic here).  You made an assumption that "foo"
will always be the top level of a module and anything "below" that is a
submodule.  And yes, luasocket works that way, and possibly most modules
work that way (I don't know, while I have downloaded every rockspec from the
LuaRocks website, I haven't don't a full analysis yet) it's not *every*
module.  A repackaged, correct, version of this would be (possibly---it's not
my project and I have no code to try this with):

org_conman_env
org_conman_env/1_0_1+3
org_conman_env/1_0_1+3/__meta.lua
org_conman_env/1_0_1+3/Linux
org_conman_env/1_0_1+3/Linux/x64
org_conman_env/1_0_1+3/Linux/x64/-org_conman_env.so
org_conman_env/1_0_1+3/Linux/x86
org_conman_env/1_0_1+3/Linux/x86/-org_conman_env.so
org_conman_env/1_0_1+3/OSX
org_conman_env/1_0_1+3/OSX/x64
org_conman_env/1_0_1+3/OSX/x64/-org_conman_env.so
org_conman_env/1_0_1+3/OSX/x86
org_conman_env/1_0_1+3/OSX/x86/-org_conman_env.so
org_conman_env/1_0_1+3/Windows
org_conman_env/1_0_1+3/Windows/x64
org_conman_env/1_0_1+3/Windows/x64/-org_conman_env.dll
org_conman_env/1_0_1+3/Windows/x86
org_conman_env/1_0_1+3/Windows/x86/-org_conman_env.dll

  Then my other modules could be included just as easily:

org_conman_syslog
org_conman_syslog/2_1_2+1
org_conman_syslog/2_1_2+1/__meta.lua
org_conman_syslog/2_1_2+1/Linux
org_conman_syslog/2_1_2+1/Linux/x64
org_conman_syslog/2_1_2+1/Linux/x64/-org_conman_syslog.so
org_conman_syslog/2_1_2+1/Linux/x86
org_conman_syslog/2_1_2+1/Linux/x86/-org_conman_syslog.so
org_conman_syslog/2_1_2+1/OSX
org_conman_syslog/2_1_2+1/OSX/x64
org_conman_syslog/2_1_2+1/OSX/x64/-org_conman_syslog.so
org_conman_syslog/2_1_2+1/OSX/x86
org_conman_syslog/2_1_2+1/OSX/x86/-org_conman_syslog.so
org_conman_syslog/2_1_2+1/Windows
org_conman_syslog/2_1_2+1/Windows/x64
org_conman_syslog/2_1_2+1/Windows/x64/-org_conman_syslog.dll
org_conman_syslog/2_1_2+1/Windows/x86
org_conman_syslog/2_1_2+1/Windows/x86/-org_conman_syslog.dll

  I do see a problem as I look with luasocket, but again, that can be
handled as well.  It may not match your asthetic viewpoint, but ...

socket_ftp
socket_ftp/2_0_2+603
socket_ftp/2_0_2+603/__meta.lua
socket_ftp/2_0_2+603/init.lua
socket_http
socket_http/2_0_2+603
socket_http/2_0_2+603/__meta.lua
socket_http/2_0_2+603/init.lua
socket_core/2_0_2+603
socket_core/2_0_2+603/__meta.lua
socket_core/2_0_2+603/Linux
socket_core/2_0_2+603/Linux/x64
socket_core/2_0_2+603/Linux/x64/-socket_core.so
socket_core/2_0_2+603/Linux/x86
socket_core/2_0_2+603/Linux/x86/-socket_core.so
	... and so on

  Treat the module names as opaque identifiers.  Why not this?

org.conman.env
org.conman.env/1_0_1+3
org.conman.env/1_0_1+3/__meta.lua
org.conman.env/1_0_1+3/Linux
org.conman.env/1_0_1+3/Linux/x64
org.conman.env/1_0_1+3/Linux/x64/-org.conman.env.so
org.conman.env/1_0_1+3/Linux/x86
org.conman.env/1_0_1+3/Linux/x86/-org.conman.env.so
org.conman.env/1_0_1+3/OSX
org.conman.env/1_0_1+3/OSX/x64
org.conman.env/1_0_1+3/OSX/x64/-org.conman.env.so
org.conman.env/1_0_1+3/OSX/x86
org.conman.env/1_0_1+3/OSX/x86/-org.conman.env.so
org.conman.env/1_0_1+3/Windows
org_.onman.env/1_0_1+3/Windows/x64
org.conman.env/1_0_1+3/Windows/x64/-org.conman.env.dll
org.conman.env/1_0_1+3/Windows/x86
org.conman.env/1_0_1+3/Windows/x86/-org.conman.env.dll

  Honestly, I don't know Windows enough to know if it can handle filenames
like 'org.conman.env'.  Linux and OS-X can.  But even if they can't, you
could still simplify the layout (I'm using '.' because they're easier to
type):

org.conman.env/1.0.1+3/__meta.lua
org.conman.env/1.0.1+3/linux-x86-org.conman.env.so
org.conman.env/1.0.1+3/linux-x64-org.conman.env.so
org.conman.env/1.0.1+3/osx-x86-org.conman.env.so
org.conman.env/1.0.1+3/osx-x64-org.conman.env.so
org.conman.env/1.0.1+3/win-x86-org.conman.env.dll
org.conman.env/1.0.1+3/win-x64-org.conman.env.dll

  Just a suggestion---again, I have no idea if this would fly on Windows. 
Actually, now that I'm thinking about it, why not this?

org.conman.env/1.0.1+3/__meta.lua
org.conman.env/1.0.1+3/linux-x86.so
org.conman.env/1.0.1+3/linux-x64.so
org.conman.env/1.0.1+3/osx-x86.so
org.conman.env/1.0.1+3/osx-x64.so
org.conman.env/1.0.1+3/win-x86.so
org.conman.env/1.0.1+3/win-x64.so

> > > When I get around to implement rocks aggregation (meaning all your
> > > rocks will end up under a single org package), you'll be free to opt
> > > out if you want to.
> >
> >   ORG IS NOT THE NAME OF MY MODULES!  HOW MANY TIMES DO I HAVE TO SHOUT
> > THAT BEFORE YOU UNDERSTAND?!
> 
> At this point, I wonder if you're being sarcastic.

  I'm wondering the same thing about you.

  -spc