Disclaimer. Luvit doesn't need luvit-pkg, use NPM instead

[voronianski]

@songgao Do luvit really needs it now? I think that's absolutely unnecessary because we have support for npm starting from the latest version 0.8.2!

https://github.com/luvit/luvit/blob/master/ChangeLog#L31

It's quite easy to manage Luvit modules with time-proven package manager. Other important thing that it will help to bring new community and make it more active. The only thing that Luvit misses right now is an active community. NPM is familiar for Node.js developers which can consider in contributing and switching to Luvit!

I think we need to concentrate on creating more useful open-source packages. That will help a lot new-comers to not reinvent the wheel. If you have such ones, do not hesitate and publish them to npm. That will make Luvit stronger!

Share your thoughts!

That's a small example app that I've created to show how easily you can use luvit modules from npm - https://github.com/voronianski/luvit-npm-example

/cc @rphillips @robert-chiniquy @creationix

[songgao]

@voronianski Thanks for the comments! I agree that we need to concentrate on creating great luvit packages!

My primary concern on using npm is whether it's a good idea mixing node.js and luvit packages together. Sure you can have a luvit- prefix on each luvit package, but the problem is:

• This makes luvit packages second-class citizens, whereas they should be as same level as node.js packages;
• Prepending luvit- to package names means you have to use luvit- prefix when requiring modules. For now, you can have node- prefix in repo names, but without that prefix in package names (e.g. https://github.com/isaacs/node-semver/blob/master/package.json). And you push that into npm, it'll work without the prefix because the package name doesn't have that prefix. If we mix luvit package into npm, we need to start use luvit- prefix in package names, which doesn't seem necessary in context of a module written in one language (lua/luvit).

I don't think we have plans on implementing a registry like npm in the near future though. Current plan is simply using git repos with simple version comparison. This way, people don't have to build a new registry. The community still use the tools they are familiar with to write packages and use packages, but the tool is made just for luvit.

[voronianski]

@songgao I don't see any problem in ommiting luvit- prefix in modules. The most important part is to tag it inside package.json with keywords as luvit and that's it!

NPM provides better possibility in searching for the right thing (tools like http://eirikb.github.io/nipster/ etc.)

I don't want to have a mix of package loaders in my app.. Maybe you've heard there is already one package installer for luvit which is called lui - https://github.com/dvv/luvit-lui, other people use git submodules, another ones just commit dependencies inside the project..

But guys, let's have one major option and it should be NPM in my opinion. It provides simplicity!

For example your organization (https://github.com/virgo-agent-toolkit) has a bunch of interesting luvit modules like luvit-stream, async etc. but for using it I will need to find out the way.. All of them should be published into NPM already, adding package.json file with the right info and updating with new version is not that hard IMHO. No special effort.

[songgao]

@voronianski hmm.. what if we want to make a semver for luvit? There's already a semver in npm so the luvit version will have to be luvit-semver right?

Also in order for this to work, we'll need to either 1) have both package.lua and a package.json. Because package.lua is what luvit recognizes right now. This is important for package meta data, and critical for packages that are not using init.lua as entry point; or 2) support package.json so that it not only loads modules from node_modules directory (as introduced in https://github.com/luvit/luvit/commit/1c071b0c54232b6d9ddbbf7132c4354f6bc3bd22), but also looks for package.json files to be compatible with npm.

Not that it won't work. It will work, but feels a bit weird to me :-)

Making another package manager doesn't mean you have to keep multiple package managers in your system, as long as everybody follows the same logic that luvit's require uses (https://github.com/luvit/luvit/blob/master/lib/luvit/module.lua and https://github.com/virgo-agent-toolkit/luvit-resolve). The package manager is what ensures that all dependencies are there at the right places, and provides useful functions.

Any way this will be a big decision that'll affect many future projects. I'm interested to see what others in this thread and other luvit developers think.

[wscherphof]

Granted - it can feel a bit weird. Then again, it's perfectly usable. Having an awesome package manager is one big preclusion for luvit and initiatives alike to gain some much needed usability. Creating and maintaining an awesome package manager means a whole chain of mountains to climb. npm readily offers great views from the tops of most of those mountains. Requiring the npm package would generate tons of instant value.

[voronianski]

@wscherphof it's not that weird, especially if you worked with node.js before.

@songgao according to your example with semver, as for me in such cases to have prefix is not such painful comparing to the advantages that are brought by NPM.

Also I would like to point an example.. How I should install your module https://github.com/virgo-agent-toolkit/luvit-template-stream with all dependencies and use it? How exactly you do it?

There's no consistency.. I would like to see something like lpm install luvit-template-stream in README and everybody will know what to do and how to start. In our case let's replace lpm with npm and enjoy the profit!

[robert-chiniquy]

Good morning! Exciting to see such a dynamic conversation about luvit.

I think I understand your concerns about seeing a luvit package management tool in development. You're eager to see a luvit ecosystem coalesce, and worried both about fragmentation of registries as well as seeing effort go to reinventing the wheel.

I was interested when npm support was added to luvit. Building anything to try to reach parity with npm would be ridiculous. Definitely a whole chain of mountains to climb. Virgo doesn't need the majority of npm's features yet though. I do agree with @wscherphof that using npm for luvit packages can feel a bit weird. npm has some luvit packages on it, but not so many that it feels like the overwhelming majority are using it. We can publish our modules to npm, but not all of us are sure we want to use it for our luvit projects.

Effort hasn't been put into a luvit package manager in a while. We all have our own ideas about what it would look like. I think most of us think of something that works like npm, though @creationix mentioned a novel idea using js-git. @voronianski mentioned lui— lui was a hard project 3 years ago because there were very few modules and not very much in luvit core to solve the problem with (like you see in this commit https://github.com/dvv/luvit-lui/commit/53de522288d229a6b4af5591e2cfaf1c6f556c81).

This is an experiment in making a simple tool to manage dependencies for Virgo packages. Like @songgao says, there is no registry so fragmentation isn't a concern. The intent is that it will support a use case like @voronianski suggests with something like lpm install luvit-template-stream. Currently our projects like luvit-template-stream use git submodules where the best you can hope for is a Makefile. Soon they should support a 1 step install. Looking at luvit-pkg you see it's using git clone. Just adding semver to this, with no other features, covers most of our current needs for package management.

The only thing that Luvit misses right now is an active community.

I totally agree. Writing anything in luvit is hard without an ecosystem. So far this repo is about 300 lines of code. It's using 5 modules we've written. It's the first project using streams with childprocess. We have a feeling that completing this should be easy so we aren't worried about wasted effort. Our goal is to make something very simple that we can use, using modules like stream-fs, and to make doing it in pure luvit look easy. We hope that projects like this will help build an active community.

[wscherphof]

I still don't see what it is that you try to accomplish then that you cannot already do with npm out of the box. Op 22 jul. 2014 17:48 schreef "Robert Chiniquy" notifications@github.com:

Good morning! Exciting to see such a dynamic conversation about luvit.

I think I understand your concerns about seeing a luvit package management tool in development. You're eager to see a luvit ecosystem coalesce, and worried both about fragmentation of registries as well as seeing effort go to reinventing the wheel.

I was interested when npm support was added to luvit. Building anything to try to reach parity with npm would be ridiculous. Definitely a whole chain of mountains to climb. Virgo doesn't need the majority of npm's features yet though. I do agree with @wscherphof https://github.com/wscherphof that using npm for luvit packages can feel a bit weird. npm has some luvit packages on it, but not so many that it feels like the overwhelming majority are using it. We can publish our modules to npm, but not all of us are sure we want to use it for our luvit projects.

Effort hasn't been put into a luvit package manager in a while. We all have our own ideas about what it would look like. I think most of us think of something that works like npm, though @creationix https://github.com/creationix mentioned a novel idea using js-git. @voronianski https://github.com/voronianski mentioned lui— lui was a hard project 3 years ago because there were very few modules and not very much in luvit core to solve the problem with (like you see in this commit dvv/luvit-lui@53de522 https://github.com/dvv/luvit-lui/commit/53de522288d229a6b4af5591e2cfaf1c6f556c81).

This is an experiment in making a simple tool to manage dependencies for Virgo packages. Like @songgao https://github.com/songgao says, there is no registry so fragmentation isn't a concern. The intent is that it will support a use case like @voronianski https://github.com/voronianski suggests with something like lpm install luvit-template-stream. Currently our projects like luvit-template-stream use git submodules where the best you can hope for is a Makefile. Soon they should support a 1 step install. Looking at luvit-pkg you see it's using git clone. Just adding semver to this, with no other features, covers most of our current needs for package management.

The only thing that Luvit misses right now is an active community.

I totally agree. Writing anything in luvit is hard without an ecosystem. So far this repo is about 300 lines of code. It's using 5 modules we've written. It's the first project using streams with childprocess. We have a feeling that completing this should be easy so we aren't worried about wasted effort. Our goal is to make something very simple that we can use, using modules like stream-fs, and to make doing it in pure luvit look easy. We hope that projects like this will help build an active community.

— Reply to this email directly or view it on GitHub https://github.com/virgo-agent-toolkit/luvit-pkg/issues/2#issuecomment-49757842 .

[voronianski]

@robert-chiniquy thanks for your thoughts, I've got your point.

So luvit-pkg is more a local solution. From my side I would still recommend to add npm as an option for all virgo packages.

[voronianski]

The small follow up on this :v:

NPM is now the world's largest package manager

[robert-chiniquy]

I enjoy this comment from ceejbot: https://github.com/nothingissacred/meatspace/issues/1#issuecomment-51511234

[pablobcb]

so, I'm coding a expressjs clone in luvit, and now need a test framework for doing so. I will probably reimplement mochajs, and add it as a dependency to the express clone.

at the moment, I am extremely confused about the packaging topic. Should i use lit? npm?

(dont know if this is the right place for asking these questions, but the luvit-wiki has brought me here)

[creationix]

@pablobcb yes, we are currently busy in rebuilding luvit from the ground up as luvit 2.0. Lit is the way forward and is already quite capable.

As an example of a web framework I built, checkout the web-app lib used in https://github.com/creationix/rye

I just wrote docs for publishing native modules using lit, I'll write another wiki page for pure lua modules next. https://github.com/luvit/lit/wiki/Publishing-Compiled-Code

[creationix]

Since the web-app lib isn't published yet, it's still in my local libs folder at https://github.com/creationix/rye/blob/master/libs/web-app.lua

With the new require system, there are two modules folders. One is called deps and is manged by lit. The other is libs and is meant to be managed by git and usually isn't published to lit.

Both folders are in the search path for the new require. You can see the lit packages I depend on in this app at https://github.com/creationix/rye/blob/master/package.lua#L6-L14.

Note that luvit is now simply a set of libraries. In this app, I'm not using all of luvit since I prefer coroutines to callbacks, so I'm cherry picking a subset of luvit. Other apps like virgo want to use the entire luvit ecosystem can depend on the metapackage directly. https://github.com/virgo-agent-toolkit/virgo-base-agent/blob/luvi-up/package.lua#L5

[creationix]

As far as test framework, I'm using this one for luvit. It's not published to lit yet. https://github.com/luvit/luvit/blob/luvi-up/tests/libs/tap.lua. The luvit unit tests show usage https://github.com/luvit/luvit/blob/luvi-up/tests/test-fs.lua

[creationix]

See also https://github.com/luvit/lit/wiki/Creating-Your-First-Package and https://github.com/luvit/lit/wiki/Package-Metadata

[pablobcb]

thank you for the detailed and fast response :)