Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guix Package #6

Open
jgarte opened this issue Jul 5, 2021 · 5 comments
Open

Guix Package #6

jgarte opened this issue Jul 5, 2021 · 5 comments

Comments

@jgarte
Copy link

jgarte commented Jul 5, 2021

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
Copy link
Owner

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

@jgarte
Copy link
Author

jgarte commented Jul 5, 2021

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
Copy link
Owner

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
Copy link
Author

jgarte commented Jul 6, 2021

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
Copy link
Owner

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. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants