search

alphapapa / bashcaster

An actually simple screen recorder for Linux
GNU General Public License v3.0
46 stars 4 forks source link

Guix Package #6

Open jgarte opened 3 years ago

jgarte commented 3 years ago

Hi I'm looking to package this either for Guix upstream inclusion or a custom guix channel.

Are you still using this script?

It seems very useful :)

alphapapa commented 3 years ago

Hi, yes, I use it when I need to record a screencast. I'm glad you're going to package it.

jgarte commented 3 years ago

Hi, yes, I use it when I need to record a screencast. I'm glad you're going to package it.

cool! should I take the latest release? 0.1?

It will be interesting to package it for guix since we have to patch all the places in the script where a program is called and add those programs as inputs (guix jargon for direct dependencies).

We just did a similar job with ytfzf: http://issues.guix.gnu.org/49238#14

I have a script for doing screen recording with ffmpeg but it is definitely not as nice as bashcaster :)

alphapapa commented 3 years ago

cool! should I take the latest release? 0.1?

I guess that's up to you. That tag is equivalent to the current master now. I don't have any specific plans for how to develop this in the future. For small scripts like this I don't usually even tag releases, but I was asked to tag one (#4), so I did.

It will be interesting to package it for guix since we have to patch all the places in the script where a program is called and add those programs as inputs (guix jargon for direct dependencies).

We just did a similar job with ytfzf: http://issues.guix.gnu.org/49238#14

I don't understand this. I have studied Guix a little bit (there's so much about it that I still don't grok), and I use it inside my Linux distro to help me run newer versions of some software. Why is it necessary to hard-code full paths to executables in the script itself? I understand the concept of package inputs, but I thought those are declared manually in the package definition, in the Scheme code. Having to modify the script itself this way seems wildly impractical. If I ran Guix as my system distro, would I have to modify my own scripts like that?

I have a script for doing screen recording with ffmpeg but it is definitely not as nice as bashcaster :)

I'm glad you like it. It seemed like all of the scripts I found online had awkward UIs for what should be a relatively simple task. Please let me know if you ever have any suggestions.

jgarte commented 3 years ago

Having to modify the script itself this way seems wildly impractical. If I ran Guix as my system distro, would I have to modify my own scripts like that?

@alphapapa see the conversation below in the logs from #guix today. I asked the communtity to see what their answer would be for that question:

https://logs.guix.gnu.org/guix/search?query=alphapapa

cbaines and apteryx responded with some answers.

Here's some mailing list discussion about the wrap-program approach that cbaines mentioned https://lists.gnu.org/archive/html/guix-devel/2014-09/msg00358.html

alphapapa commented 3 years ago

Thanks for doing that.

Having read those, I wonder if patching the executable names to be absolute paths is necessary here. The rationale given was to ensure that the script behaves as expected, calling the expected versions of executables rather than ones which may behave differently. I don't think it's likely that executable version changes are going to cause a malfunction here; and if some day, maybe years from now, something changed in one of those programs and it did break something, well, this script isn't explicitly targeted at any versions of other software, anyway. It's just a simple Bash script.

Alternatively, I wonder if packaging simple scripts like this is even suitable for Guix. I don't object to your doing so, of course, but it seems like a lot of unnecessary work, patching executable names, for not much benefit.

Of course, I'm not a Guix maintainer, so what do I know. :)