package manager for awesome modules,extensions,etc

[ivanbalashov239]

i believe it is one of the biggest issues of awesome community, don't you think that it would be a lot simplier if we had standard way to add new libraries, modules and extensions to our configs? there is luarocks out there, but there are only few packages for awesome Should we:

• use luarocks
• write the new one
• use system package managers
• leave as it is

[blueyed]

Since luarocks is the Lua package manager using it seems sensible?! System package managers can then be used on top as usual.

I am not using many libs myself, and then git is just fine.

[mindeunix]

as far as I remember @Elv13 has some ideas

2016-08-02 00:20:41 Elv13_ minde: Ping, I am trying to build a huge branch with all the widgets in the universe for upstreaming after 3.6 is released. Could you package some of your widgets into proper lua files?

Anyway, I don't like the luarocks way, but it would be great to have a awesomeWM/extensions repository with all extensions/modules.

[aajjbb]

I really liked this idea, although I have mixed feelings about using luarocks, it seems both specific and generalist in the same time.

I'd vote to write a new one that can be easily wrapped by system package managers.

[hishamhm]

Hi there, I'm the lead developer of LuaRocks (and an Awesome WM user :) ) and I've been using it successfully to handle Awesome extensions (and module dependencies! — e.g. I wrote a widget that requires luafilesystem).

We would love to support the Awesome community with package management. We already have a nice command-line app (luarocks install foo, luarocks upload foo) and the luarocks.org server with search, tags, etc.

The Lua community is small, so I think every opportunity to join efforts should be considered. :)

[ivanbalashov239]

@hishamhm that's awesome news, now when we know that luarocks already part of our community, we should find a way to build module dependency system and tradition for awesomewm, @mindeunix , @aajjbb could you describe what you don't like in luarocks, maybe it will help @hishamhm make it better, and maybe someone of us will help develop luarocks. @hishamhm a little feature request: it would be simplier if packages could be just git repositories, like in golang

[aajjbb]

It's great to see that @hishamhm is in LuaRocks (he's everywhere :smile: )

I was afraid that LuaRocks could be too generalist (it can host any Lua package), so that users could get lost in such a myriad of packages.

One way to improve it is to create tags for Rocks in LuaRocks, in a way that all awesome extension will have some tag identifying them so.

[hishamhm]

@hishamhm a little feature request: it would be simplier if packages could be just git repositories, like in golang

We still require the rockspec metadata file so that we can have, well, metadata ( :) ) and searchability in luarocks.org, but you can make it point to a git repo (e.g. https://luarocks.org/manifests/hisham/datafile-0.2-1.rockspec — we do plan to make the modules section optional in LuaRocks 3 assuming sane defaults such as *.lua and src/*.lua, so that a rockspec really can be just the metadata)

I was afraid that LuaRocks could be too generalist (it can host any Lua package), so that users could get lost in such a myriad of packages.

If a strict separation is found to be really necessary, luarocks.org does have support for hosting separate "manifests" (essentially separate index files), so that when a user runs luarocks search foo they only get results from that manifest.

But I think using the awesome label would be enough for finding Awesome stuff on the website easily, and it would allow modules to depend on non-awesome-specific modules (this already happens: the pulseaudio_widget that's there depends on lua-dbus), so I think the best approach is to just use the main manifest and mark Awesome modules with the awesome label.

[mindeunix]

@hishamhm that's awesome news, now when we know that luarocks already part of our community, we should find a way to build module dependency system and tradition for awesomewm, @mindeunix , @aajjbb could you describe what you don't like in luarocks, maybe it will help @hishamhm make it better, and maybe someone of us will help develop luarocks.

I do not like package managers way because they require extra work, and I do not think that willl change something, if someone wanted to use LuaRocks they already use it. Having awesomeWM/extensions repository (like Weechat and others) allows us to create issues, feature requests and help each other to fix problems.

Also, we already lost awesome.naquadah.org/wiki (many outdated stuff), we can generate a list with all awesomeWM/(extensions,themes!?) and include it to API documentation.

[psychon]

I do not like package managers way because they require extra work

I read this as "I want a simple example with a step-by-step tutorial on how to do this". Perhaps some git repo with a library doing return "Hello world" and a README.md explaining how to get this into Luarocks?

Having awesomeWM/extensions repository (like Weechat and others) allows us to create issues, feature requests and help each other to fix problems.

I don't know how Weechat does this (and Google didn't immediately answer that question), but who has commit access to this? (I won't ask how users are supposed to handle updates...) Any minimal amount of code review will stop contributions (more so if I do so; sorry for being so strict) and this might still contain outdated/broken stuff.

[mindeunix]

I do not like package managers way because they require extra work

I read this as "I want a simple example with a step-by-step tutorial on how to do this". Perhaps some git repo with a library doing return "Hello world" and a README.md explaining how to get this into Luarocks?

No, I had in mind that "I will not use any package manager at all."

I don't know how Weechat does this (and Google didn't immediately answer that question), but who has commit access to this? (I won't ask how users are supposed to handle updates...) Any minimal amount of code review will stop contributions (more so if I do so; sorry for being so strict) and this might still contain outdated/broken stuff.

There is more than one way to do it, one of the easiest just creating a new repository with README.md file with links to all extensions.

[ivanbalashov239]

@mindeunix do you use LFS or sluck? :) anyway i believe there is compromise, if packages will be git repositories, so you will be able to add them as submodules to your config repository, and others will be able to use package manager. It looks like the only way to make it mainstream, is to create packages for all popular modules/extensions, and part of this job is the list of them. And actually we need developers of most popular addons to be agree with the idea of package manager.

[ivanbalashov239]

@hishamhm here is the case how i want to use package manager:

• I create git repo(on github for example) with manifest file and everything, so correct package structure.
• I use packagemanager luarocks install github.com/seniorivn/apw/tree/3.5 and it's gonna check if this repository is correct package, and if it is, it will install it, and depends on settings upload to the luarocks server information about it, so you will be able to add this to the search database.

I'm sorry i didn't check how it works for now, but i believe it's the best way.

[mindeunix]

@mindeunix do you use LFS or sluck? :)

No, I'm using Gentoo and most of the stuff I use-most is custom-build my self :-). I have nothing wrong about package managers, just thinking that in this case they are not needed.

[ivanbalashov239]

@mindeunix ok, don't you think my suggestion is the compromise between your way and package manager? You will be able to use any of them or both.

[mindeunix]

@seniorivn Well, I'm not using many extensions created by others, but I have created some of them and more is coming (I have 30k+ lines config and planning to split it to modules). I have no plans to make them available through package managers, only wanted that they be listed somewhere.

[ivanbalashov239]

@mindeunix ok, but I suppose you will confirm pull request with manifest file and instructions for luarocks usage?

If so, then there is no problem, and the list off all modules we need anyway.

[mindeunix]

@mindeunix ok, but I suppose you will confirm pull request with manifest file and instructions for luarocks usage? If so, then there is no problem, and the list off all modules we need anyway.

time will tell whether it is worth, for now :thumbsup:

[aajjbb]

If a strict separation is found to be really necessary, luarocks.org does have support for hosting separate "manifests" (essentially separate index files), so that when a user runs luarocks search foo they only get results from that manifest.

I've just seen those labels (which I called tags in my comment). So LuaRocks is a great choice.

[r3lgar]

Bad idea. It make awesome less awesome, less flexible.

[ivanbalashov239]

@funeralismatic how exactly? awesome will be flexible the same way, when you will need it, but when you don't, you could use package manager, it's win-win, don't you think?

[r3lgar]

@seniorivn how you add a plugin without edit a configuration file? How "package manager" will do it? What it should do if plugins conflict? If at least one of these questions remains unanswered your idea is worthless.

Proof of concept or die! :laughing:

[ivanbalashov239]

@funeralismatic i believe package manager for awesome-module not suppose to edit config file, awesome users should be able to do that by themself, but pm should be able to add module to the system and update it.

[r3lgar]

@seniorivn

pm should be able to add module to the system and update it

#!/bin/bash

cd "~/.config/awesome/"

function update(){
    local function upd(){
        cd "./${MOD}"
        git remote update
        if [ $(git rev-parse '@' 2>/dev/null) != $(git rev-parse '@{u}' 2>/dev/null) ]; then
            git pull
        fi
        cd "~/.config/awesome/"
    }
    if [ -z "${@}" ]; then
        for MOD in $(cat ./.modlist); do
            upd
        done
        awesome-client 'awesome.restart'
    else
        for MOD in ${@}; do
            upd
        done
    fi
}

function add(){
    local DIR="${2:-$(echo "${1##*/}" | sed "s/\.git//g")}"
    if ! grep "^\./${DIR}$" ./.modlist >/dev/null; then
        git clone "${1}" "./${DIR}"
    else
        update "${DIR}"
    fi
}

function del(){
    if [ -n "${1}" ] && grep "^\./${1}$" ./.modlist >/dev/null; then
        rm -r "${1}"
        sed -i "/\.${1}/d" ./.modlist
    fi
}

 case "${1}" in
     u) update "${@#${1} }" ;;
     a) add "${2}" "${3}" ;;
     d) del "${2}" ;;
     *) exit 1 ;;
 esac

I don't test this bullshit, lol.

[ivanbalashov239]

@funeralismatic it's a crutch, everyone can do that, but who will check dependencies and versions and etc, i don't want to do that by myself, do you? It's package managers job.

[r3lgar]

@seniorivn it's just an example. You can write ebuild/PKGBUILD-like system or whatever you need.

You want – you do. :smile:

[warptozero]

I don't think there is a good argument against using a package manager for extensions. The awesome project itself will remain unaffected and extensions will still be developed with git/github as they are now, so doing everything by hand will always still be an option.

@hishamhm Would it be possible to expose these labels on the command line? To allow searching labels and listing their contents. Or would this be a lot of work/somehow a bad idea?

With a simple wrapper/alias to this

luarocks --tree=~/.config/awesome/luarocks --only-label=awesome

it would then also be possible to implement a more awesome specific package manager (if necessary) without reinventing the wheel.

[hishamhm]

@warptozero Adding label-specific actions would be quite some work (and compatibility headaches) because it would change the protocol, but one option that is already supported would be to have an "awesome" manifest in the luarocks.org server (a manifest is like an index of modules). For example, here's one for the Tarantool database:

https://luarocks.org/m/tarantool

It is as if Awesome then has its own server. The awesome-specific search then would be:

luarocks search --server=http://luarocks.org/m/awesome <name>

The LuaRocks config file allows setting aliases to server URLs, so one could write --server=awesome, for example.

(Thinking about it, adding a command-line flag that did this automatically without editing the config file wouldn't be too much work. Combining this with auto-manifests for labels on the server side (@leafo?) and we'd get the --label=awesome feature... doesn't sound like a bad idea at all!)

[leafo]

@hishamhm shouldn't be an issue, will have to use a different url base to avoid conflicting with usernames

[DanielVartanov]

While we are all here, can I ask why awesome's rc.lua does not see libraries installed via luarocks? No matter whether they are installed locally or globally, awesome always says module 'a-lib-installed-via-luarocks' not found?

[psychon]

@DanielVartanov All I can say on that question is: Because the library was not installed to Lua's default search path. Perhaps a different Lua version? I don't know. You can use awesome-client 'return package.path' to get the search path and compare that with where luarocks installed things to.

Also, you can try adding require("luarocks.loader") to your rc.lua. That should make it possible to find locally installed packages (but globally installed ones should always be findable). (Yes, this was added to the default config a while ago)