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. On Mon, Nov 28, 2016 at 10:21 AM, Lionel Duboeuf <[email protected]> wrote: > 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 > > > > > > > Le lundi 3 octobre 2016 22:33:38 UTC+2, Tim Caswell a écrit : >> >> 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 >> >> On Tue, Sep 27, 2016 at 9:07 PM, Tim Caswell <[email protected]> wrote: >> >>> 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) >>> >>> On Mon, Sep 26, 2016 at 5:25 PM, Dmitri Voronianski < >>> [email protected]> wrote: >>> >>>> But what about lit and luarocks? As I understand luvit will use native >>>> requires? >>>> >>>> 26 сент. 2016 г., в 23:06, Tim Caswell <[email protected]> >>>> написал(а): >>>> >>>> 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. >>>> >>>> On Mon, Sep 26, 2016 at 3:03 PM, Dmitri Voronianski < >>>> [email protected]> wrote: >>>> >>>>> 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. >>>>> >>>>> 2016-09-26 21:17 GMT+02:00 Tim Caswell <[email protected]>: >>>>> >>>>>> 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 `[email protected]` >>>>>> 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 >>>>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fsqueek502%2Fluver&sa=D&sntz=1&usg=AFQjCNF9-HveEsDBX00ocIuL4_vAeLXkNw> >>>>>> 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 >>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>>> 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 [email protected]. >>>>> 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 [email protected]. >>>> 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 [email protected]. >>>> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
