lua-users home
lua-l archive

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


2017-02-26 17:32 GMT+01:00 Philipp Janda <siffiejoe@gmx.net>:
> Am 26.02.2017 um 16:36 schröbte szbnwer@gmail.com:
>>
>> hi all!
>
>
> Hi!
>
>>
>> what if instead of trees, just using simple labels, and then one can
>> check for a label, and if getting too much resoultz, then choose a
>> next one, and this way forward...
>
>
> The LuaRocks.org site imported the labels from LuaToolbox.org. So we do have
> labels (just on the site, not on the CLI). Iterative refinement of label
> selections would be a nice addition, but I more desperately miss a sorting
> by endorsement like in the old Toolbox because I usually filter the modules
> by satisfied (well-known) users first before I look for the functionality
> that I need. This way I can get rid of the 90% crap that Steve talked about.

thats also a good one, i just thought that getting any much info for
start and then narrowing can be a good way instead of making complex
graphs... but anyway ive never used luarocks and i dont even know lua
toolbox, just gave a suggestion

i thought that whatever info i want coud be displayed like package
name as default and there can be anything else useful other than
labels...

> We *could* add labels to the rockspec so that the CLI can use them, but we
> would need a way to make the rockspec authors agree on a common set of
> labels. I'd suggest to give the rockspec authors complete freedom to choose
> labels, and maintain equivalence sets and a blacklist separately.

and this one is the harder part, as it can make a big mess... maybe
there could be a verified (canonicalized) and a non verified set of
them, so anyone can put there anything, theres no further things to do
with the 1st set, and the 2nd can be moved into the 1st when a
reasonable verified label can be used instead of any custom one... so
it gives freedom as the 2nd set and reliance with the 1st

anyway i was about thinking loud only, as i'm not using luarocks (by
the lack of need, but in the future anything can happen)

> Philipp