lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On 18 February 2016 at 18:50, Tim Caswell <tim@creationix.com> wrote:
> So the killer features of lit that I'm not willing to part with are:

Nice, thanks for the list!

>  - relative imports for intra-package modules.

I did not understand this one, could you elaborate?

>  - scoped package installs (npm style) (vs global paths)

Leaf's tutorial on npm-style installs shows we have machinery in
place, but the process could definitely be made smoother.

>  - a content-addressable based sync system for downloading and publishing
> files.

We are completely lacking in this respect. Our manifest files and
rockspec format assume that "version-revision" numbers are globally
consistent identifiers (i.e. the whole world agrees that lpeg 0.10-1
refers to that one rock in the luarocks.org repo); we use md5 hashes
in local manifests only. I'm not sure exactly what we should pursue or
improve in this regard. We've been talking about improving the
addressing (but still in centralized terms; one idea that's floating
around is to be able to refer to "user/package-1.0" in dependencies).

In any case, I think I'd prefer to make sure that at least the root
manifest in luarocks.org is self-sufficient (ie, all rocks in it
depend only on rocks in it, not on arbitrary URLs). But this wouldn't
preclude adding support for more decentralized approaches too.

>  - trivially deployed proxy servers or private repositories.

I think it's feasible to implement a proxy server tool like `lit
serve` on top of the support for private repositories we already have.

> I would love for there to be one package system for lua in the future.  Lit
> isn't there yet and these are places where I find luarocks lacking.

Thank you so much for this summary! It's really helpful!

-- Hisham