-
Notifications
You must be signed in to change notification settings - Fork 4
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
Comments
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 :) |
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.
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'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. |
@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 |
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. :) |
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 :)
The text was updated successfully, but these errors were encountered: