On 05/12/2016 04:09 PM, Hisham wrote:
> if build.type is not given, assume builtin.
>
> If build.modules is not given:
> Try one of these:
> 1) if there's a src/ dir, assume everything inside it is to be
> installed according to default rules for .lua and .c files
> 2) if there's a lua/ dir, assume everything inside it is to be
> installed according to default rules for .lua files
> 3) if there are *.lua or *.c files in the root, assume they are to
> be installed according to default rules for .lua and .c files
I'm not so comfortable with this being the default behavior, both
because it seems like it would get things wrong on occasion and because
I have in the past assumed that an empty build table was the same as no
build at all. If it's hidden behind a new build type, say build.type =
'auto' we can at least hope that the user read something that explained
what it actually did and decided that would work in their case.
> When specifying dependencies:
> Add a `build_dependencies` table, checked only during `luarocks build`.
> Add a `provides` table for allowing virtual dependencies. Depending
> on a virtual dependency may specify a default suggestion ( "json
> (default to dkjson)" ).
> Range operator "to" -- "lua 5.1 to 5.3" ("<pkg> <ax>.<ay> to
> <bx>.<by>" means "<pkg >= <ax>.<ay>, < <bx>.<by + 1>")
> Optional dependencies:
> support "or" expressions in dependencies.
> support "optionally" prefix.
> Default behavior: install optional dependencies by default but
> keep going if they fail. --optionals={none,install,try (default)}
Request: A `servers` field, where you can define on a rockspec level
which servers to query in order to get dependencies. I have a bunch of
private/semi private/vendored packages that fail to install unless I
remember the right CLI incantation, and I'd rather not add them to my
system luarocks configuration and mess up packages that aren't mine.
Packages with external servers should probably not get uploaded to
luarocks.org though, for obvious reasons
Also at first blush I was going to complain about build_dependencies not
being general enough (what about test_dependencies, staging_dependencies
etc) but I think I'd need to look at other package managers to see if
people actually do use arbitrary dependency profiles when they have
access to them.
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Luarocks-developers mailing list
Luarocks-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/luarocks-developers
