styx

[jyp]

You may be interested in this tool I've made: https://github.com/jyp/styx
If you have feedback on it I'd love to hear it!

[shajra]

@jyp thanks a lot for reminding me about this project (I remember seeing a link fly by on Twitter, but I didn't follow up).

It's kind of funny. As I was reading your code, I was thinking "Is making the shell.nix as hard as I'm making it out to be? Maybe I should think about it fresh. And then I realized it could be as simple as swapping in a custom mkDerivation into the function generated by cabal2nix. And then I saw that that's exactly what you're doing with gatherDeps.

So I'm going to adjust this project to do a similar approach. After that, I won't feel like a "hack," just a reasonable solution.

As far as my review of styx, I don't think it's a bad approach at all. It introduces a tool to manage your "*.nix" files, so we don't have to think about Nix as much. My project is going down the other path -- trying to see how clean we can go just with normal Nix expressions before leaning on a tool like styx. I think there's some value in both approaches. You probably are missing some configuration option to allow people the full flexibility they'd get with raw Nix, and it's your call on whether to support those or not (maintenance isn't free). For instance, if someone wanted to turn on profiling, what's your recommended way of doing that with styx? There's two answers I can imagine: 1) just write Nix expressions that build upon the ones styx generates 2) adding more switches/configuration into styx's Main.hs source.

Thanks again for the pointer. Hopefully we can get more people using Nix where makes sense.

[jyp]

Indeed I'm not aiming at getting the full power of nix just yet. Styx mostly aims to show that one can get a system as powerful as "stack" with very minimal effort on top of nix. If someone needs some more power I'll probably accept PRs of reasonable complexity though. Thanks for your feedback!

…

On Wed, Feb 1, 2017 at 12:53 AM, Sukant Hajra ***@***.***> wrote: @jyp <https://github.com/jyp> thanks a lot for reminding me about this project (I remember seeing a link fly by on Twitter, but I didn't follow up). It's kind of funny. As I was reading your code, I was thinking "Is making the shell.nix as hard as I'm making it out to be? Maybe I should think about it fresh. And then I realized it could be as simple as swapping in a custom mkDerivation into the function generated by cabal2nix. And then I saw that that's *exactly* what you're doing with gatherDeps. So I'm going to adjust this project to do a similar approach. After that, I won't feel like a "hack," just a reasonable solution. As far as my review of styx, I don't think it's a bad approach at all. It introduces a tool to manage your "*.nix" files, so we don't have to think about Nix as much. My project is going down the other path -- trying to see how clean we can go just with normal Nix expressions before leaning on a tool like styx. I think there's some value in both approaches. You probably are missing some configuration option to allow people the full flexibility they'd get with raw Nix, and it's your call on whether to support those or not (maintenance isn't free). For instance, if someone wanted to turn on profiling, what's your recommended way of doing that with styx? There's two answers I can imagine: 1) just write Nix expressions that build upon the ones styx generates 2) adding more switches/configuration into styx's Main.hs source. Thanks again for the pointer. Hopefully we can get more people using Nix where makes sense. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABsY2xMnqo7is-d0hu4-HaxRCLrIeLDks5rX8lxgaJpZM4LzKl_> .