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...
On Wednesday, July 4, 2012 at 5:17, Tang Daogang wrote:
> 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...
On Wed, Jul 4, 2012 at 1:43 PM, Pancake <panc...@nopcode.org> wrote:
> I wrote lum as a replacement for npm in luvit.
> github/radare/lum
> On Wednesday, July 4, 2012 at 5:17, Tang Daogang wrote:
> 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...
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.
On Wednesday, July 4, 2012 at 8:29, Tang Daogang wrote:
> but lua has lurocks already?!
> On Wed, Jul 4, 2012 at 1:43 PM, Pancake <panc...@nopcode.org (mailto:panc...@nopcode.org)> wrote:
> > I wrote lum as a replacement for npm in luvit.
> > github/radare/lum
> > On Wednesday, July 4, 2012 at 5:17, Tang Daogang wrote:
> > > 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...
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.
On Wed, Jul 4, 2012 at 3:06 PM, Pancake <panc...@nopcode.org> wrote:
> 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.
> On Wednesday, July 4, 2012 at 8:29, Tang Daogang wrote:
> but lua has lurocks already?!
> On Wed, Jul 4, 2012 at 1:43 PM, Pancake <panc...@nopcode.org> wrote:
> I wrote lum as a replacement for npm in luvit.
> github/radare/lum
> On Wednesday, July 4, 2012 at 5:17, Tang Daogang wrote:
> 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...
> 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.
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.
On Wed, Jul 4, 2012 at 2:06 AM, Pancake <panc...@nopcode.org> wrote:
> 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.
> On Wednesday, July 4, 2012 at 8:29, Tang Daogang wrote:
> but lua has lurocks already?!
> On Wed, Jul 4, 2012 at 1:43 PM, Pancake <panc...@nopcode.org> wrote:
> I wrote lum as a replacement for npm in luvit.
> github/radare/lum
> On Wednesday, July 4, 2012 at 5:17, Tang Daogang wrote:
> 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...
On Fri, Jul 6, 2012 at 12:08 AM, Tim Caswell <t...@creationix.com> wrote:
> 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.
> On Wed, Jul 4, 2012 at 2:06 AM, Pancake <panc...@nopcode.org> wrote:
>> 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.
>> On Wednesday, July 4, 2012 at 8:29, Tang Daogang wrote:
>> but lua has lurocks already?!
>> On Wed, Jul 4, 2012 at 1:43 PM, Pancake <panc...@nopcode.org> wrote:
>> I wrote lum as a replacement for npm in luvit.
>> github/radare/lum
>> On Wednesday, July 4, 2012 at 5:17, Tang Daogang wrote:
>> 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...
> On Fri, Jul 6, 2012 at 12:08 AM, Tim Caswell <t...@creationix.com> wrote:
> > 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.
> > On Wed, Jul 4, 2012 at 2:06 AM, Pancake <panc...@nopcode.org> wrote:
> >> 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.
> >> On Wednesday, July 4, 2012 at 8:29, Tang Daogang wrote:
> >> but lua has lurocks already?!
> >> On Wed, Jul 4, 2012 at 1:43 PM, Pancake <panc...@nopcode.org> wrote:
> >> I wrote lum as a replacement for npm in luvit.
> >> github/radare/lum
> >> On Wednesday, July 4, 2012 at 5:17, Tang Daogang wrote:
> >> 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...
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.
On Friday, July 6, 2012 at 19:53, Brandon Philips wrote:
> 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
> > On Fri, Jul 6, 2012 at 12:08 AM, Tim Caswell <t...@creationix.com> wrote:
> > > 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.
> > > On Wed, Jul 4, 2012 at 2:06 AM, Pancake <panc...@nopcode.org> wrote:
> > > > 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.
> > > > On Wednesday, July 4, 2012 at 8:29, Tang Daogang wrote:
> > > > but lua has lurocks already?!
> > > > On Wed, Jul 4, 2012 at 1:43 PM, Pancake <panc...@nopcode.org> wrote:
> > > > I wrote lum as a replacement for npm in luvit.
> > > > github/radare/lum
> > > > On Wednesday, July 4, 2012 at 5:17, Tang Daogang wrote:
> > > > 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...
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" <panc...@nopcode.org> написал:
> 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
> On Friday, July 6, 2012 at 19:53, Brandon Philips wrote:
> 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
> On Fri, Jul 6, 2012 at 12:08 AM, Tim Caswell <t...@creationix.com> wrote:
> 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.
> On Wed, Jul 4, 2012 at 2:06 AM, Pancake <panc...@nopcode.org> wrote:
> 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.
> On Wednesday, July 4, 2012 at 8:29, Tang Daogang wrote:
> but lua has lurocks already?!
> On Wed, Jul 4, 2012 at 1:43 PM, Pancake <panc...@nopcode.org> wrote:
> I wrote lum as a replacement for npm in luvit.
> github/radare/lum
> On Wednesday, July 4, 2012 at 5:17, Tang Daogang wrote:
> 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...
> 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" <panc...@nopcode.org> написал:
> 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
> On Friday, July 6, 2012 at 19:53, Brandon Philips wrote:
>> 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
>>> On Fri, Jul 6, 2012 at 12:08 AM, Tim Caswell <t...@creationix.com> wrote:
>>>> 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.
>>>> On Wed, Jul 4, 2012 at 2:06 AM, Pancake <panc...@nopcode.org> wrote:
>>>>> 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.
>>>>> On Wednesday, July 4, 2012 at 8:29, Tang Daogang wrote:
>>>>> but lua has lurocks already?!
>>>>> On Wed, Jul 4, 2012 at 1:43 PM, Pancake <panc...@nopcode.org> wrote:
>>>>> I wrote lum as a replacement for npm in luvit.
>>>>> github/radare/lum
>>>>> On Wednesday, July 4, 2012 at 5:17, Tang Daogang wrote:
>>>>> 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...
