Igrom / i3-persist

Extends i3 window management with persistent containers
BSD 3-Clause "New" or "Revised" License
28 stars 2 forks source link

Include the library in the main script #1

Closed swflint closed 2 years ago

swflint commented 6 years ago

Doing this makes it easier to install as a system-wide script, or to package for an operating system (I plan on packaging for NixOS).

Igrom commented 6 years ago

Hey swflint, I really appreciate your interest in the package.

The code is unit tested during continuous deployment. The Travis configuration file did include a test step, but did not install shunit2, which caused the script to fail quietly on testing. This has been fixed (please merge upstream changes).

If the library is included in the main script, it cannot be tested. I am interested if you can offer a replacement solution.

Could you show me how putting the code in one file would be easier? I have to admit that I am not familiar with NixOS. What's the obstacle here?

swflint commented 6 years ago

So, as of now, the issue is the way you load the library -- you do it by sourcing the file by relative path. This requires an unusual form of installation. If you can have it sourced by absolute path -- or even consider rewriting it in python (as there's a particularly good i3 interface for python), that would make it easier.

This method of installation doesn't just cause problems for NixOS though, it would make it difficult to package for any other OS.

Igrom commented 6 years ago

I apologize for the untimely response.

A relative dependency in the script does not disallow you from placing the directory anywhere. In fact, the executable resolves its real path with readlink -f: therefore it is entirely possible to install the package in a random folder and then symlink i3-persist anywhere on $PATH.

On my machine, I link to the tool while it remains in my private development folder.

I do not understand how packaging the script is any different from any other software release with more than one file. If you can give a case for when symlinking is insufficient when packaging software, I will consider merging the code.