Re: [ANN] Lift 0.1 looking for early adopters

[Hisham <h@...>]

> On Tue, Feb 16, 2016 at 8:07 PM, Thiago Bastos <tbastos@tbastos.com> wrote:
>>
>> Hisham, thanks for showing up :-)
>>
>> So, "decentralized" package managers are a relatively new thing, made
>> possible by the popularization of DVCS and sites such as GitHub and
>> BitBucket. The advantages are pretty much analogous to the advantages of
>> "distributed" over "centralized" version control systems.
>>
>> Basically you don't have a centralized index of packages. Packages are
>> always distributed and consumed as source code. The package identifier is
>> always a URL, instead of a package name. Usually the package will be hosted
>> on a site such as GitHub and the package manager will fetch a specific
>> version (tag, release, or master) and build/install the package based on a
>> manifest file similar to a rockspec, but with a fixed name such as
>> "package.lua".
>>
>> It's a step beyond allowing "local rock servers" in terms of freedom and
>> flexibility, and it would probably simplify LuaRocks by a fair margin. No
>> more servers, no more binary distributions, etc. All efforts can be focused
>> on the build system, versioning and dependency management.

Thanks for the explanation and pointers!

I can definitely see how this simplifies things and I'm happy to see
package management go in this direction. I do however see value in
the centralized luarocks.org as a community focal point (especially
in a small and emerging community such as ours).

The fact that  the _management_ of rocks has become decentralized
within luarocks.org (as opposed to the curated repo of the early
days) has been a big boost to the project. We should definitely
try to make things quicker and more flexible, but I don't see us
dropping support for centralized model any time soon.

>> For example, see [1] for an example of how to specify dependencies in a
>> distributed package manager.
>>
>> Currently the most prominent distributed package manager is Apple's new
>> Swift package manager. It's being developed by Max Howell, the original
>> author of Homebrew (the most successful package manager for OSX). See [2]
>> and [3].

Oh, so _that's_ the guy I should have asked about their stated
GoboLinux influence. :)

-- Hisham

>
> [1]
> https://github.com/Carthage/Carthage/blob/master/Documentation/Artifacts.md#example-cartfile
> [2]
> https://github.com/apple/swift-package-manager/blob/master/Documentation/PackageManagerCommunityProposal.md
> [3]
> https://github.com/apple/swift-package-manager/blob/master/Documentation/Package.swift.md
>
>
>
> On Tue, Feb 16, 2016 at 11:22 PM Hisham <h@hisham.hm> wrote:
>>
>> On 16 February 2016 at 19:35, Thiago Bastos <tbastos@tbastos.com> wrote:
>> > Tim,
>> >
>> > I love that you're reconciling your projects with the vanilla Lua
>> > ecosystem.
>> > To be honest I had looked into Luvit roughly a year ago and was
>> > simultaneously impressed and put off by the fact that it was a separate
>> > ecosystem and didn't "improve" upon Node.js. I always thought a Lua
>> > rendition of Node.js exploiting coroutines and other Lua features could
>> > make
>> > Node.js look feeble by comparison. I'm happy that you're addressing both
>> > issues :-)
>> >
>> > I think I see the reasons why you couldn't use luarocks and had to
>> > create
>> > lit. In my idealistic opinion, however, I think both ecosystems (Luvit
>> > and
>> > LuaRocks) would be better off by joining forces in the future. It would
>> > be
>> > awesome if Lua had only one package manager, and you could install
>> > Luvit/weblit from it.
>> >
>> > If you feel the same, I would love to hear what you think would be
>> > necessary
>> > for a merger. A new package manager?
>> >
>> > Personally I'd be in favor of a new decentralized package manager based
>> > on
>> > just Lua and libuv. If possible with legacy support for LuaRocks
>> > packages.
>> > Could it be LuaRocks 3.0? Lit 2.0?
>>
>> Hi! Chiming in just to say I'm listening and enjoying this
>> conversation and open for suggestions for improvement and
>> collaboration. I'd love to hear which features are perceived as
>> lacking in LuaRocks in this context. For instance, what do you mean by
>> "decentralized package manager"? (Note that LuaRocks has support for
>> local repositories: --server can even point to local directories, but
>> you probably mean something else).
>>
>> Also, there's a LuaRocks survey online that's open for receiving feedback:
>> http://bit.ly/luarocks
>>
>> Thanks!
>>
>> -- Hisham
>>
>> > On Tue, Feb 16, 2016 at 7:21 PM Tim Caswell <tim@creationix.com> wrote:
>> >>
>> >> I just wanted to chime in here as the creator of Luvit.
>> >>
>> >> First I think Lift is a great project.  I'm glad my luv bindings are
>> >> helping others.
>> >>
>> >> Secondly, the comparison is accurate for luvit proper, but there is
>> >> much
>> >> more to the luvit ecosystem than just the luvit metapackage.
>> >>
>> >> The luvit package aims to be a complete node.js port in lua.  This is
>> >> why
>> >> it's callbback based and has very similar APIs.
>> >>
>> >> That said, I'm not a fan of callbacks in lua. I think it's a shame to
>> >> have
>> >> native coroutines in a language and not use them.
>> >>
>> >> For the last year or so, I've been writing apps and libraries using
>> >> luv,
>> >> but with coroutines for servers and clients.  The lit package manager
>> >> itself
>> >> it implemented at a luvi app (not luvit) and doesn't use luvit's
>> >> standard
>> >> library.  It has it's own coro-* libraries that are much easier to use.
>> >> I've also written an HTTP web framework on top of these coro-*
>> >> conventions
>> >> at https://github.com/creationix/weblit
>> >>
>> >> I'm sorry that I haven't documented this new development as well as I
>> >> should for newcomers to find it.
>> >>
>> >> If you want to do task automation, Lift looks great. If you want to
>> >> write
>> >> TCP servers, use the coro-* libraries published to lit.
>> >> https://luvit.io/lit.html#coro
>> >>
>> >> Also I've recently been working on an effort to make luvit's ecosystem
>> >> more widely available to non-luvit developers.  Most all the popular
>> >> libraries are now in a format that can be used by lua directly without
>> >> luvit's custom require loader.  I've even written a custom lua loader
>> >> that
>> >> implements a lit compatible path resolution algorithm, but uses lua's
>> >> native
>> >> require (and so mixes freely with luarocks packages).
>> >>
>> >> If anyone is interested, I can write up a blog post on using these
>> >> libraries from vanilla lua.
>> >>
>> >> -Tim Caswell
>> >>
>> >> On Sun, Feb 14, 2016 at 7:12 AM, Thiago Bastos <tbastos@tbastos.com>
>> >> wrote:
>> >>>
>> >>>
>> >>> On Sat, Feb 13, 2016 at 3:53 PM Nagaev Boris <bnagaev@gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> On Sat, Feb 13, 2016 at 5:15 PM, Thiago Bastos <tbastos@tbastos.com>
>> >>>> wrote:
>> >>>> > Good question!
>> >>>> >
>> >>>> > I think the three major points for comparison are the following:
>> >>>> >
>> >>>> > 1) Luvit is a runtime for (mostly) server-side applications, while
>> >>>> > Lift
>> >>>> > focus on being a framework for client-side tools, mostly
>> >>>> > development
>> >>>> > tools
>> >>>> > (I'm using it to write a dev tool for C++). In this respect, Lift
>> >>>> > is
>> >>>> > more
>> >>>> > similar to Gulp/Grunt/Jake/NPM than to Node.
>> >>>>
>> >>>> Can Lift be used to create TCP server?
>> >>>
>> >>>
>> >>> Technically you could create a TCP server using only luv. That would
>> >>> be
>> >>> fairly low level though, and I'm not sure which abstractions included
>> >>> in
>> >>> Luvit/Node you'd be missing (depends on your application I guess).
>> >>>
>> >>>>
>> >>>> There are applications which are both servers and clients: proxies,
>> >>>> torrent clients, caching DNS resolvers. Can I implement them in Lift?
>> >>>>
>> >>>> > 2) Luvit adopts Node's Continuation Passing Style (callbacks),
>> >>>> > which
>> >>>> > is
>> >>>> > conducive to "callback hell" and in my opinion more difficult to
>> >>>> > reason
>> >>>> > about. Lift implements a Direct Style in which concurrency is
>> >>>> > achieved
>> >>>> > with
>> >>>> > coroutines and without callbacks (which in my opinion leads to much
>> >>>> > simpler
>> >>>> > code).
>> >>>>
>> >>>> >From https://luvit.io/ :
>> >>>> > If you don’t like callbacks and event emitters, use coroutines and
>> >>>> > write blocking style code without actually blocking your event
>> >>>> > loop!
>> >>>
>> >>>
>> >>> Yes, but that's a very theoretical statement. In practice you need to
>> >>> create lots of abstractions, a scheduler, etc. In Lift all the work
>> >>> has
>> >>> already been done, and it took me a lot of work. All blocking calls in
>> >>> Lift
>> >>> use coroutines behind the curtains and you don't even need to know
>> >>> what a
>> >>> coroutine is.
>> >>>
>> >>>>
>> >>>> > 3) While Lift fits into the standard LuaRocks ecosystem, Luvit
>> >>>> > decided
>> >>>> > to
>> >>>> > create its own ecosystem, with its own package manager and tools.
>> >>>>
>> >>>> I think, it is a strong point of Lift.
>> >>>>
>> >>>> > I'd say the only thing Luvit and Lift really have in common is that
>> >>>> > both
>> >>>> > projects use the "luv" library (the libuv bindings created for
>> >>>> > luvit,
>> >>>> > to
>> >>>> > which I'm also a contributor).
>> >>>> >
>> >>>> > Cheers!
>> >>>> >
>> >>>> > On Sat, Feb 13, 2016 at 1:45 PM Nagaev Boris <bnagaev@gmail.com>
>> >>>> > wrote:
>> >>>> >>
>> >>>> >> On Sat, Feb 13, 2016 at 3:33 PM, Thiago Bastos
>> >>>> >> <tbastos@tbastos.com>
>> >>>> >> wrote:
>> >>>> >> > Dear list,
>> >>>> >> >
>> >>>> >> > I'd like to announce the first (v0.1) release of Lift, a
>> >>>> >> > general-purpose
>> >>>> >> > task automation tool for Lua with support for multitasking,
>> >>>> >> > streams
>> >>>> >> > and
>> >>>> >> > asynchronous I/O powered by libuv. It's available on luarocks
>> >>>> >> > and
>> >>>> >> > works
>> >>>> >> > on
>> >>>> >> > Linux, OSX and Windows.
>> >>>> >> >
>> >>>> >> > Lift was inspired by projects such as Rake, Gulp and npm, but
>> >>>> >> > follows a
>> >>>> >> > unique Lua-ish design. Check out the full list of features at:
>> >>>> >> >
>> >>>> >> > https://github.com/tbastos/lift
>> >>>> >> >
>> >>>> >> > I'm currently looking for early adopters or even contributors to
>> >>>> >> > help
>> >>>> >> > guide
>> >>>> >> > the development. Would you rather use Lua to automate your
>> >>>> >> > development
>> >>>> >> > workflow? Do you think Lua is currently missing a more powerful
>> >>>> >> > build
>> >>>> >> > tool/task runner/other development tool? Please check out the
>> >>>> >> > project
>> >>>> >> > and
>> >>>> >> > give your feedback, say which features are important and so
>> >>>> >> > forth.
>> >>>> >> >
>> >>>> >> > Cheers!
>> >>>> >>
>> >>>> >> Hi!
>> >>>> >>
>> >>>> >> Thank you for Lift!
>> >>>> >>
>> >>>> >> What is the relationship between Lift and Luvit [1]. Can you
>> >>>> >> compare
>> >>>> >> them, please?
>> >>>> >>
>> >>>> >> [1] https://luvit.io/
>> >>>> >>
>> >>>> >> --
>> >>>> >>
>> >>>> >>
>> >>>> >> Best regards,
>> >>>> >> Boris Nagaev
>> >>>> >>
>> >>>> >
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>>
>> >>>>
>> >>>> Best regards,
>> >>>> Boris Nagaev
>> >>>>
>> >>
>> >
>>
>