[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [SUGGESTION] Some lfs functionality in os library, please!
- From: steve donovan <steve.j.donovan@...>
- Date: Thu, 8 Sep 2016 10:16:13 +0200
On Wed, Sep 7, 2016 at 4:40 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> Every time I require lfs, I ask myself: why is this stuff not in the
> os library?
I have some sympathy, but it's good that the core distribution remains
lean & mean.
First observation is that what scripters (particularly newcomers) need
is a _distribution_.
A platform-independent example is luarocks, which practically means
'soruce-based distribution'. LR can deliver pre-compiled rocks but
binary compatibility remains difficult - even on a classic consumer OS
like Windows (mingw or MSVC runtime? Which particular runtime?).
Although getting old in the tooth, Lua for Windows did the job for
many. The LuaDist-based 'batteries' distribution is more modern and
can be built easily from scratch.
Integrating these distributions with LuaRocks isn't that
straightforward - you definitely want something that's extensible!
Debian has a rather good collection of Lua modules available, which is
what I leveraged with ldeb - a quick and dirty way of packaging
scripts and libraries as .deb files.
luabuild is a mini-distribution designed around two ideas (1)
completely local installation and (2) ability to create custom
standalone executables. There have been a number of re-inventions ;)
[0]
At which point, my favourite Grace Hopper quote: "The wonderful thing
about standards is that there are so many to choose from". This
diverse ecosystem with different solutions does get a little confusing
to the newcomer (and we all start as newcomers). This is why what
Ryan Putzai did with Lua for Windows is important.
Python _is_ damn convenient, I will admit. Part of that is the
default, much-maligned kitchen sink, which becomes a liability when
deploying. We have a surprisingly rich collection of third-party
modules available but no grand unified documentation...
[0] definitely needs a re-visit though....