Packaging default scripts about i3blocks-contrib HOT 22 CLOSED

You are totally correct. There shouldn't be any hard dependencies to i3blocks, the C core doesn't use external libraries and default scripts are just provided as a convenient drop-in replacement to i3status.

I think part of the decision has to be how you want to position i3blocks: is it just a framework and the scripting is up to the user – or do you want to provide a preconfigured drop-in replacement that can be modified afterwards?

i3blocks is currently packaged as the second option. But this has just shown us that it generates lots of subjective changes, which I want to avoid. And it can upset minimalist users as well (not everybody has a laptop with battery or cares about bandwitdh.)

Thus I share your preference on the former option, that is where I want to bring the project.

An helpful message is the way to go then. This as well as a FAQ, links and documentation will work.

There's a slightly different way as well: if you can determine that a blocklet calls a script (rather than an inlined command), check on startup whether the script exists. If the script of none of the default blocks exists, display some error message. It's just a vague idea and could be improved; I'm not sure you'd wanna go down this kind of route at all, though.

Shells return 127 for command not found, that is easily identifiable. I'm totally fine with providing explicit messages for system-generic issues. What I don't want to do is inspecting user-provided strings for instance.

from i3blocks-contrib.

What's wrong with the default config location at /etc/i3blocks/i3blocks.conf?

Here is my setup btw:
one /etc/i3blocks/i3blocks.conf
and then I have all scripts in /usr/local/lib/i3blocks/
I just set the path in the config to that folder..

from i3blocks-contrib.

Hi @shibumi,

Sorry I wasn't clear. The default config location is fine. What I was talking about is moving out the default scripts from the i3blocks source repository to i3blocks-contrib, so that i3blocks will only contain the C core, and i3blocks-contrib will contain all scripts (defaults + user contributed.)

Unless I'm wrong, this means that distro maintainers will have to fetch i3blocks sources as well as the default scripts from i3blocks contrib in order to package i3blocks properly.

Would that be an issue for you?

from i3blocks-contrib.

@vivien nope, that is totally fine. I would just split i3blocks in two packages. One i3blocks package and one i3blocks-contrib package with additional scripts.

from i3blocks-contrib.

Great then. Just curious, if someone does pacman -S i3blocks, the status line will be functional thanks to something like this?

$ pacman -Si i3blocks
...
Name            : i3blocks
...
Depends On      : i3blocks-contrib
Optional Deps   : None

$ pacman -Si i3blocks-contrib
...
Name            : i3blocks-contrib
...
Depends On      : acpi: For battery script
                            bc: For bandwidth script
                            ...
Optional Deps   : playerctl: For mediaplayer script
                           ...

from i3blocks-contrib.

Yes, this would be correct. But maybe it would make more sense when the users just clone the i3blocks-contrib repository, because you don't have a release cycle for i3blocks-contrib. Furthermore I have no idea what Arch Linux Developers would say about that move.

So my current plan would be:

$ pacman -Si i3blocks
...
Name            : i3blocks
...

If a user wants the i3blocks-contrib repository he just need to git clone it in a directory.

from i3blocks-contrib.

We can do releases in i3blocks-contrib, that is not a problem. What I'm worried about is that if one issues pacman -S i3blocks, (s)he won't have a functional status bar. The package needs to provide the default scripts somehow (as it is currently done).

from i3blocks-contrib.

If I may weigh in to give my 2c – if i3blocks is delivered with a default config that requires some blocklet scripts to be there, they should either be part of i3blocks or part of some kind of i3blocks-scripts package. i3blocks-contrib, to me, sounds like an additional collection of contributed scripts; but here we are instead talking about scripts required for i3blocks to function.

from i3blocks-contrib.

That's correct @Airblader. I want to make life simpler for (i3blocks* and package) maintainers as well as for users. What I want to avoid is there is currently several entry points to suggest changes to the scripts. Either users sends a PR for i3blocks' default scripts, or they suggest a new contrib script in i3blocks-contrib. We can end up with duplicates (like the default bandwidth script and the 2 contrib alternatives.)

Now if i3blocks sources do not include default scripts anymore, how do we provide some to the users? Some randoms thoughts are: add a new i3blocks-contrib package dependency to i3blocks? inject i3blocks-contrib into i3blocks' scripts/ directory before packaging? i3blocks-contrib may be renamed if there is confusion here?

i3blocks could also display something if there is no blocklets or config file found. Because there are lots of subtleties between distros, we can imagine distro-specific config and scripts in this repository, etc.

How as a user/maintainer you'd like to see this managed?

from i3blocks-contrib.

The problem with adding a hard dependency on i3lock-contrib is that you force a package on users who might not need it at all – this is of course up to the package maintainer to decide, but typically this will upset some people.

On the other hand, optional dependencies have a tendency not to be installed which might cause you a »i3blocks doesn't work« issue every few weeks. This is more or less the situation we have with i3bar and i3status where i3bar will give you a rather unhelpful error message if you haven't installed i3status.

I think part of the decision has to be how you want to position i3blocks: is it just a framework and the scripting is up to the user – or do you want to provide a preconfigured drop-in replacement that can be modified afterwards?

Personally, I'd like to see i3blocks as the former of the two and thus your suggestion of

i3blocks could also display something if there is no blocklets or config file found.

appeals to me, given that the message would be more helpful than what i3bar tells you. That approach does increase efforts for a user ever so slightly, but I don't think it's a terrible burden. Just make sure to guide the user to easily find their way (and to avoid tickets :-) ).

There's a slightly different way as well: if you can determine that a blocklet calls a script (rather than an inlined command), check on startup whether the script exists. If the script of none of the default blocks exists, display some error message. It's just a vague idea and could be improved; I'm not sure you'd wanna go down this kind of route at all, though.

from i3blocks-contrib.

Hello (sorry for the late reply..)

While I can understand the reasoning for shipping i3blocks separately from all the blocklets, from a package maintainer (and user) perspective this cause an issue:

i3blocks would have to depend/recommend on i3blocks-contrib (There is no way I am uploading something to Debian that does not work out of the box, it is not reasonable for me to tell users to install blocklets from git..). There's already a lot of scripts in i3blocks-contrib, and they would all need their dependencies added in the package as well (If they are distributed through a package, scripts should be expected to work once they're installed).

Installing i3blocks would then bring a LOT of dependencies. For someone who just wants the small/basic functionality of i3blocks, it can be problematic.

A possible solution:

I could split the i3blocks-contrib package in two: one for the (current) default, and one for the extra (i3blocks-scripts i3blocks-extras for example). Thoughts?

This is my (highly subjective) opinion of course, welcoming opinions on this.

from i3blocks-contrib.

@vivien @Airblader I would strictly split up scripts and i3blocks-bar. The scripts are for me just a form of 'configuration'. I don't use them. I even don't use the contrib scripts because they don't do exactly what I want.

So for me I would have no problem with splitting up i3blocks and i3blocks-contrib (for scripts only).

EDIT: If you want to see i3blocks-contrib packaged. Please schedule releases via github (would be cool if you could sign these releases with a GPG key. Same for i3blocks btw)

from i3blocks-contrib.

Sorry for the double post, but I didn't want to edit my last post twice.

@jpleau Do you don't have something like optional dependencies in Debian?
In Arch Linux this could look like this. Thats how the optional dependencies for i3blocks look at the moment:

Optional Deps   : acpi: For battery script
                  bc: For bandwidth script
                  lm_sensors: For temperature script
                  openvpn: For openvpn script
                  playerctl: For mediaplayer script
                  alsa-utils: For volume script
                  sysstat: For cpu_usage script

I would split up i3blocks in i3blocks and i3blocks-contrib. In i3blocks-contrib I would have i3blocks-contrib as optional dependency for i3blocks and in i3blocks-contrib I would optional or hard depend on all dependencies for the scripts. Not sure yet if I optional or hard depend on them. Most likely I would do optional dependencies. So the users could pick out the scripts what they want to use and what not.

from i3blocks-contrib.

@vivien @Airblader I would strictly split up scripts and i3blocks-bar. The scripts are for me just a form of 'configuration'. I don't use them.

That's exactly what @vivien and I agreed on above as well. :-)

from i3blocks-contrib.

@shibumi Yes we do have something similar. "Recommends" and "Suggests" are what they are named. They are similar but have different meaning (see: https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.en.html#s-depends)

By default, both automatically install packages on the user's system, but you can disable either or both.

I could see something like this:

I would create a default config for debian users (or use the one provided if it's shipped with i3blocks-contrib), and add dependencies for scripts included in this one as "Recommends" (ie: you should install those if you want it to work out of the box), and for the other scripts, add their dependencies as "Suggests" (ie: you enabled those scripts on your own, and by disabling suggested packages being installed you might be missing a few things).

Also, +1 for signed releases !

from i3blocks-contrib.

I have a long term gpg key, but I've never used it for code signing purposes. If there is interest in that I don't think it would be difficult to start signing releases. Is it best practices to make one code signing key or a separate code signing key just each package? Please recommend me what to do.

I like @jpleau's suggestion, make the default script config hard dependencies and then just suggest deps for blocklets that are not in the default config.

from i3blocks-contrib.

Next release of i3blocks will be signed then ;-)

@jpleau, is that acceptable for you as a packager to ship i3blocks + some default scripts manually picked from i3blocks-contrib?

While having releases for i3blocks-contrib makes sense to match updates in i3blocks, I'm not even sure it'd be necessary to package it. But that is up to the distro packager though. It would even make sense to see per-distro default configuration files in the contrib repository, so that distributions can share and decide what they ship as an out-of-the-box solution.

from i3blocks-contrib.

@vivien Would work for me.

I also wouldn't mind packaging i3blocks-contrib and depending on it as an optional dep. Whatever is easier for the others I'll adjust my stuff :)

from i3blocks-contrib.

I've just released v1.4.0 as a catchup release to i3blocks. The goal will be for compatible i3blocks-contrib and i3blocks to have the same major and minor version number. Releases are signed with my gpg key 6E59B8E5A268E206A086329E507E1F837C14FFA9.

from i3blocks-contrib.

PSA to others reading this thread, i3blocks-contrib is ready to merge next into master when the same is true for i3blocks

from i3blocks-contrib.

Support for dynamic properties is merged into i3blocks master. The default scripts have been removed from the i3blocks sources, from now on the i3blocks repository only contains the C scheduler. The bar now displays fatal errors such as config file or command not found.

from i3blocks-contrib.

@vivien I've merged the next branch into master here as well, closing this issue. Thanks for your work.

from i3blocks-contrib.