Why luvit doesn't be compatible with lua's require mechanism

[Tang Daogang]

hi,

 

Why luvit doesn't be compatible with lua's require mechanism?

 

luvit can copy nodejs' require mechanism, but can also backfall to lua  and luarcks' require mechanism. What is the reason make you discard the default lua require mechanism.

 

So now luvit lacks a package management tool like npm...

--
Nothing is impossible.

[Pancake]

I wrote lum as a replacement for npm in luvit.

github/radare/lum

[Tang Daogang]

but lua has lurocks already?!

--
Nothing is impossible.

[Pancake]

This is the third time i have to explain this, so...let's go:

I wrote lum for fun, not for wanting to kill or critize luarocks. So, from now on is just a personal project, not a trolling foo.

Imho luarocks is nice but doesnt fit in luvit at all. Mostly because of this:

- lum uses async stuff based on libuv, so packaging stuff for luvit in luarocks is wrong beause the db will contain packages that cant run on vanilla lua.

- luvit module system is different to how lua module loading works. Installation paths, linking options, api depedencies, enforced async io...

- lum can at some point reuse luarocks packages but honoring the luvit require system. So, lum completes luarocks, but not replaces.

- lum packages are just a json file, like in npm. And they are referenced by another json that can be uploaded anywhere. This is. Lum allows to create a distribute network of package providers using web technologies. Luarocks cant do this.

- lum supports native and lua based modules and aims to impose a standard in the luvit ecosystem.

- lum has been written on top of luvit, so it's 20% funnier (or more)

- i didnt count lines, but lum is like 10% of the code of what luarocks is and it does the same

- lum supports git and zip sources.

I just did this as a proof of concept for fun in just an afternoon. If you find this disturbing just dont use it, as far as i know nobody but me uses it, it has not even been listed in the creationix presentation. Dunno if this was to avoid discussions like this or just because he dont cares.

I think that luvit needs a specific package manager, but thats just a personal feeling. I believe that if many people think like that and use lum then lum can became the standard pkg system for luvit, else it will remain there foreveralone.

That's the beauty of free software and community driven projects.

I just don't want to spend time giving explanations, because i feel that if i have to give them im doing something wrong.

[Tang Daogang]

I see.

 

Nodejs need npm, because there is no primary package management tool in js world, but lua has.

 

In fact, it doesn't matter how many package management tool in lua world, but the how many modules matter. I didn't see many packages in lum repository.

If luarocks is not satisfied, we'd better to propose schema to luarocks.

--
Nothing is impossible.

[pancake]

On 07/04/12 09:15, Tang Daogang wrote:
> I see.
> Nodejs need npm, because there is no primary package management tool
> in js world, but lua has.
> In fact, it doesn't matter how many package management tool in lua
> world, but the how many modules matter. I didn't see many packages in
> lum repository.
>

as i said lum will support luarocks packages at some point (unless i got
tired of discussing about it and remove the project source or i find it
pointless).

native luarocks modules (90% of them) doesnt work with luvit. and the
10% missing
which is just lua code will not work without modification because of the
same reason.

if lum aims to support luarocks packages it should wrap its build,
source and installation
system of the luarocks packages.

as far as duckduckgo can tell. luarocks is from 2007 (but i remember
using it some years before.. or maybe i'm wrong), this is at least 5
years of history. my code is just
half a year with 0 contributors.

i don't really care about the number of packages if i can't use any of them.

--pancake

[Tim Caswell]

I don't want luarocks integration.  It pollutes luvit for the reasons pancake explained so well.

The reason I left lum out of my slides is because I simply haven't had time to play with it.  I'm very glad the tool exists and I hope it gets more attention.

Luvit as it stands today isn't very approachable.  The docs are either wrong or non-existent.  Most everyone using luvit either knows the node api already or learned the luvit API the hard-way (reading source and asking questions).

Since we want to draw in a larger community, we should fix this.  Lum or something like it made specifically for luvit is required.  I don't have the time to do this myself, so I'm glad others are thinking about it.

[Tang Daogang]

pancake, can you update your lum and pack more libraries now.

--
Nothing is impossible.

[Brandon Philips]

On 10:00 Fri 06 Jul 2012, Tang Daogang wrote:
> pancake, can you update your lum and pack more libraries now.

Please don't make demands of people in open source communities.

Filing bugs you encounter, contributing code and discussing ideas on the
mailing list are positive ways to interact in this community.

Thank You,

Brandon

[Pancake]

I've been playing a bit with luarocks and definitively we can't recycle many things from there.

Native modules doesnt work because of linking form, require paths fail and most (all) of them are sync.

I believe that luvit is a different ecosystem, where you can copypasta code from lua projects in the same way as you do when taking js code from a website to make it run in nodejs.

I've very little time to do stuff in lum nowadays, but I would like to have more modules to play with and feedback from all you to know what would you like to change or enhace.

My plan was to make lum like npm, but distributed. In the form that you can have multiple sources from 3rd party people and use local search for finding packages (this is already done). But what will rock is to have a website to search, download, rate modules. Having a commandline frontend for it would really benefit the platform.

Do we have a list of modules written for luvit? Would u mind to package it.

Thanks

[Vladimir Dronnikov]

luarocks is good at making your project os-neutral. it derives cflags et al. on its own freeing developer from this routine and error-prone stuff. it allows to install deps 'locally' meaning under project's root. when these features are in lum, there'll be much less call for luarocks

06.07.2012 23:48 пользователь "Pancake" <pan...@nopcode.org> написал:

[pancake]

Lum supports dependencies, install stuff locally and abstracts compiler flags from os. Actually just linux/osx. All you mention there is already done.

The compilation part can be done better. Because right now depends on a makefile.

[Wouter Scherphof]

I was thinking npm https://github.com/luvit/luvit/pull/447

npm does a great job in managing modules, it's actually not constrained to JavaScript content in any way, and it's arguably well known already to anyone interested in luvit