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 <t...@creationix.com > <javascript:>> 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 < >> dmitri.vo...@gmail.com <javascript:>> wrote: >> >>> But what about lit and luarocks? As I understand luvit will use native >>> requires? >>> >>> 26 сент. 2016 г., в 23:06, Tim Caswell <t...@creationix.com >>> <javascript:>> написал(а): >>> >>> 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 < >>> dmitri.vo...@gmail.com <javascript:>> 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 <t...@creationix.com >>>> <javascript:>>: >>>> >>>>> 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 >>>>> `luvit@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 >>>>> <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 luvit+un...@googlegroups.com <javascript:>. >>>>> 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 <javascript:>. >>>> 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 <javascript:>. >>> 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 <javascript:>. >>> 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
