Nixpkgs: sway: How to package the scripts in contrib/

[primeos]

Background

Since the introduction of grimshot there is some demand to package the contributed scripts for Sway: https://github.com/swaywm/sway/tree/master/contrib

• autoname-workspaces.py: Adds icons to the workspace name for each open window
  
  
  
  • Not useful to package, code must be customized (WINDOW_ICONS)
  
  
• grimshot: A helper for screenshots within Sway
  
  
  
  • The most popular script (useful to package)
  
  
• inactive-windows-transparency.py: Makes inactive windows transparent
  
  
  
  • Could be useful to package since transparency_val can be changed from the CLI (-o option)
  
  

Additional scripts might(/will) be added in the future. All scripts should obviously only (or at least mainly) be useful for Sway.

Question

How should we package these scripts in Nixpkgs. Do we include all relevant scripts in a single package (e.g. sway-contrib or sway.contrib) or do we add a package for each relevant script?
Feel free to state your position (ideally also why) and/or add arguments ;)

Arguments

Note: This is WIP/incomplete.

• New: Use a package set, e.g. sway-contrib (with sway-contrib.grimshot, etc.)
  
  
  
  • Should combine the advantages of both of the following options
  
  
  • Currently seems like the best option
  
  
• A single package (draft: https://github.com/primeos/nixpkgs/commit/2b079e57ddd470db7ea28debb8066035eb5ab10c)
  
  
  
  • Doesn't get out of hand if a lot of new scripts appear
  
  
  • Easier to discover
  
  
  • It is clear that the scripts are only intended to be used with Sway
  
  
• One package per script (Grimshot: #87831)
  
  
  
  • Smaller closure (each script has only its own dependencies - a user doesn't have to install all dependencies for just one script)
  
  

[Synthetica9]

Maybe package them in a seperate swaytools set (is that the correct term), that has the advantage of both I think:

• Small closure
• Easy to discover: nix search on the name of the script instead of some abstract "swaytools" package
• Clear that it's only intended to be used with Sway
• Natural discovery of the rest of the scripts: nix search grimshot would give nixos.swaytools.grimshot, a natural second action would be nix search swaytools giving all the tools. We currently have a similar situation with other window managers; nix search konsole; nix search kdeApplications for example.

[evils]

i like the package set suggestion
i considered a nixpkgs.sway.contrib set, but dismissed it as i didn't realize the set as a whole could be discovered (i would prefer grimshot to not be burried in an opaque attribute)

to me the most important things are having a separate pname and/or description to be found with nix search (and secondarily found with find nixpkgs/ -name "pname")

and as i'm not familiar with the other items in /contrib keeping at least those that have dissimilar dependencies/implementations separate seems nice so if i'm listed as a maintainer on grimshot i don't get pinged when something goes wrong with the python scripts

[primeos]

@Synthetica9 Nice, I like that idea, thanks :)

Regarding the name: I think we should go with sway-contrib (or sway.contrib but that will probably cause problems with discoverability and is nested one level deeper) to make the origin as clear as possible and avoid collisions. E.g. for swaytools there is already a GitHub project (though it is not that popular yet and only packaged in the AUR and PyPI so far: https://github.com/tmccombs/swaytools). Current packages: https://repology.org/projects/?search=sway

If someone has a better name I'm open for suggestions :)

[evils]

is the intention to restrict this to stuff from sway/contrib/?
in that case, having it be sway.contrib makes that very clear.
if not, calling it contrib could stop people from adding to it and i'd go with swayUtils (no name confict with camelCase)

[primeos]

is the intention to restrict this to stuff from sway/contrib/?

I thought so, but now that you mention it we could drop that restriction and use e.g. swayUtils (as you've suggested).

in that case, having it be sway.contrib makes that very clear.

I didn't look into this but AFAIK sway.contrib will unfortunately not work as desired since we cannot use recurseIntoAttrs for sway(?) and therefore the sub-packages wouldn't be discoverable via nix search etc (though there might be another way to do this).

[evils]

i think it's best to explicitly limit the scope to stuff from sway/contrib/
otherwise we risk creating a recommended set of sway related utilities, and get questions like, "why isn't swaylock-effects included in this"
if we want to do that, it can include sway-contrib

how about this? https://github.com/NixOS/nixpkgs/compare/master...evils:sway-contrib

[primeos]

otherwise we risk creating a recommended set of sway related utilities, and get questions like, "why isn't swaylock-effects included in this"

Right

how about this? https://github.com/NixOS/nixpkgs/compare/master...evils:sway-contrib

The sway-contrib part LGTM (but I e.g. don't see the need for the alias).

[primeos]

Solution (proposal): Use a package set (sway-contrib) limited to all relevant tools from https://github.com/swaywm/sway/tree/master/contrib (i.e. sway-contrib.grimshot, etc.)

Is someone against this or did I miss something?

[evils]

an issue (in my opinion) with this approach is that there's barely 1.5 packages worth of stuff in contrib/

and since grimshot seems fairly generic (going by the comments, just the window selection is sway specific) i wouldn't be surprised if that gets split off.

i'm mostly going along with the package set approach because of your concern that more stuff could appear, curiosity about how to deal with such matters
and because with an alias, where the implementation sits is quite irrelevant.

[evils]

not sure if people following this issue got notified, but i opened #88577 implementing the solution apparently agreed to here