wip/perfect flake adoption

[blaggacao]

• flakify this repository
• wip
• ca

@siraben This is just a first pass; if you want to have a look.

next steps:

• merge & update themes
• merge & update styx-site
• adapt styx.sh as "look&feel"-wrapper into the nix bundle iface
• adapt tests
• adapt docs content

[NickHu]

I'm grateful for your work @blaggacao on modernising styx, it certainly needed some love. However, I have a major concern.

I'm a skeptical about moving away from the standard flake paradigm to std. It might make styx more esoteric than it needs to be, and std's documentation is nowhere near viable.

For instance, I have a few patches that I apply to styx (e.g. use pandoc instead of multimarkdown), and I have no idea how to do this with your new flake (the previous one 46aee6d38fa6c142d85001d62fb041a744037d67 worked quite nicely). I'd need to override src in https://github.com/styx-static/styx/blob/9782317f43779ba7be4924e1ed0dd72dfda68168/flake.nix#L45 and I have no idea how to do that.

Granted, this is probably due to my unfamiliarity with std, but I suspect many flake users will be unfamiliar too. That's not to say that I couldn't be convinced, but my current preference is for merging https://github.com/styx-static/styx/pull/65 over this PR.

[blaggacao]

Hey @NickHu thank you for your comment/review.

At this point, my brain simply works best to organize things using std, because of the clear enforcing of interfaces.

I would even go so far that at this point, it's essential mental scaffolding for me, to shuffle things around with confidence (and somewhat speed).

(I also have to say that the previous flakification is still far from complete, as is this draft PR, here.)

For example, due to the hassle of coordinating template updates across the orga, I have some draft commits to move everything into a mono-repository, just to make our all lives easier.

I could propose two things:

• revert the std scaffolding (which helps me being productive) when done
• add a full "traditional" flake output compatibility layer (so that it looks and quacks normally)

Since, when moving into monorepo space, std is just a abstractable way of organizing files in the repo in lieu of some creative ad-hoc ordering principles, I would personally rather tend to the latter option. In such, we can keep the ordering principles in good company to help us maintain styx more easily in the future.

(I also expect that one of the major adopters of styx might be a std-shop, so we may see more easy influx of contributions)

PS: Totally unrelated to this repo, but I'd be absolutely greatful for a couple of issues on std w.r.t. its documentation. It should become not only viable, but absolutely must become perfect. There's no alternative to that.

PPS: let me have a closer look at your use case going forward. i think I'll eliminate the need for modifying src since the styx CLI shall simply become sugar for the nix bundle interface, and I heck will make sure that you will be able to call out to a forked bundler.

PPPS: I might find some further time to go about the business of this PR in the coming days, so let's also see how far I get with the primary refactoring goal.

[garbas]

Please don't use std for everything @blaggacao, it really makes the bar to understand how things work really high. I understand it makes it easier for you to think, but it make it really impossible for even experienced nix developers to contribute to any project that uses std. And I know this since I'm still trying to understand how std works after 6 months of using it at work. This is definitely not a fun experience I want others to go through.

I was hoping to use it for nixos.org to replace what we have there, but I will definitely don't want to force others who want to help out with the website to have to understand std. One of main reasons to actually select styx for nixos.org is that many more nix engineers would be able to understand how nixos.org is built. With the adoption of std main reason wont be true anymore, which I guess we will have to look for other static site generators.

Anyway, I just wanted to raise my concern. The decision is anyway in the hands of the maintainer.

[blaggacao]

This PR has three goals:

• Update Styx
• Increase subjective maintainability
• Increase objective maintainability

No further side conditions. I don't see at all a sustained conflict between the latter two points:

• Excessive black magic is obviously a strong signal.
• However, path dependency is a bit of a weaker signal.

Thanks for the data point!

[garbas]

@blaggacao Will styx be using std, either internally or externally? I would really appreciate a straight answer: yes/no.

[blaggacao]

@garbas I shared what I know. But your argument is also a rethorically & semantically mixed bag, and I don't want to take the full invitation at this point.

I think the goals are clear and I don't see any problem with them.

[blaggacao]

This is going to be broken up, the themes are already in-tree and the devshell instrumentation is initiated on master. Closing here.