Proposal for luvit 3.0

[Tim Caswell]

Luvit 2.0 has been stable for a while now, the refactor to split into luv, luvi, and luvit was a great success.  Now it seems the major issues are around documentation and what's legacy support and what people should be using for new projects.

There are two competing interests currently.

1. Large legacy projects that use luvit in production and depend on the node.js style libraries as well as the exact semantics of the original luvit 1.0 require system (that replaces lua's require).

2. New luvit projects that want a clean start and are confused about the strange behavior or the luvit 1.0 require (hint, I didn't know lua very well when I designed it).

I propose we republish the current luvit system as `luvit-node` or something to signify that it's a node.js clone in lua.

Then with the main `luvit` namespace free, we can publish `lu...@3.0.0` which uses the new luvit-loader require logic the same as lit.  We can also remove all non-essential libraries to make this core less opinionated.

Basically the idea is to take https://github.com/squeek502/luver and make it the main `luvit` that is the base everything else builds on top of. (we'll still have the raw luvi option for people wishing to make single-binary applications as well)

what do you all think?

-Tim Caswell

[Dmitri Voronianski]

Hi,

I recently started to update my luvit packages to luvit 2.0 - https://github.com/luvitrocks/ as well as writing API in luvit. As for me it will nice to have luvit and lit stable and add more features to them. I think lit and luvit will be more successful only in current shape.

--
You received this message because you are subscribed to the Google Groups "luvit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to luvit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Best regards,

Dmitri Voronianski

[Tim Caswell]

What do you mean "only in current shape"?  I won't be changing any of the APIs and the current set of APIs in the 'luvit' package will still be available.  They will just require being included in your app's dependencies the same as any other non-core dependencies.  The newly renamed `luvit-node` metapackage will still pull in the entire luvit 2.x standard library.  So at most, you'll need to add a single line to your package.lua to migrate to luvit 3.0 from luvit 2.0.

Also with a reduced scope in the core and switching to a saner require system, I'll have more time and ability for actually writing docs.

[Dmitri Voronianski]

But what about lit and luarocks? As I understand luvit will use native requires?

26 сент. 2016 г., в 23:06, Tim Caswell <t...@creationix.com> написал(а):

To unsubscribe from this group and stop receiving emails from it, send an email to luvit+un...@googlegroups.com.

[Tim Caswell]

I'm proposing switching to the require system that lit uses internally.  It's a custom lua require loader that extends the native require to know about luvit style require paths instead of the luvit 1.x style require that wholesale replaces require and then falls back to native if not found.

The new system is much cleaner and works with even plain luajit or lua and luv.so. (see https://luvit.io/blog/pure-luv.html)

[Tim Caswell]

I just put up a PR for moving luvit to the new require system.  If you're concerned about breaking changes, test this version of luvit against your app and let me know (here or in the PR) what your problems are.  There are some obscure breaking changes around the edges of the require system, but on the whole, the major semantics stay the same and the internals clean up a lot!

https://github.com/luvit/luvit/pull/932

[Lionel Duboeuf]

i agree with Luvit 3.0 proposal. The cleaner, the better ;-)
Trying to avoid breaking change can lead also to really confusing things... (i was afraid when i saw Tim's last blog post about luvit-loader, my thoughts were: "oh no, things getting really complicated now! ;-)"


regards
Lionel

To unsubscribe from this group and stop receiving emails from it, send an email to luvit+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Best regards,

Dmitri Voronianski

--
You received this message because you are subscribed to the Google Groups "luvit" group.

To unsubscribe from this group and stop receiving emails from it, send an email to luvit+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "luvit" group.

To unsubscribe from this group and stop receiving emails from it, send an email to luvit+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "luvit" group.

To unsubscribe from this group and stop receiving emails from it, send an email to luvit+un...@googlegroups.com.

[Tim Caswell]

The main blocker right now with luvit 3.0 is designing how we want require to work (and interact with lit). 

It turns out that we can't magically add relative require to lua's require without some nasty edge cases that break in horrible ways (name collisions in the internal cache).

Once we figure out what luvit 3.0 exactly is.  I'm more than happy to cut a release and support 2.x and 3.x concurrently for a while to see if everyone moves over to 3.

To unsubscribe from this group and stop receiving emails from it, send an email to luvit+unsubscribe@googlegroups.com.