Logs: liberachat/#haskell
| 2021-08-14 17:10:13 | → | keutoi joins (~keutoi@223.182.21.173) |
| 2021-08-14 17:10:34 | <maerwald> | also: stack vs cabal isn't a "company" decision... I can use any stack build system with cabal |
| 2021-08-14 17:10:37 | <maerwald> | I decide myself :) |
| 2021-08-14 17:10:51 | <aegon> | for a new comer that is far too many optoins, i'm really curious about nix since its gaining traction from my "gut" feeling talking with others in haskell land but it feels wierd to me. |
| 2021-08-14 17:10:53 | <maerwald> | in public projects, I want stack.yaml and cabal.project likewise |
| 2021-08-14 17:11:02 | <sclv> | aegon: the standard cabal (nix-style) builds now give you the isolation between projects without sacrificing the resolver notion, so it sounds like that might be the simplest approach to start with |
| 2021-08-14 17:11:23 | <aegon> | I don't really understand it but from what i grokk it feels like giving up on compatible / generic code and making os blot containers for every lib version ever and relying on isolation to deal with vulnerabilities? |
| 2021-08-14 17:11:30 | × | wonko quits (~wjc@62.115.229.50) (Ping timeout: 268 seconds) |
| 2021-08-14 17:11:37 | <dminuoso> | aegon: 3 is just a slight improvement of 1 in my opinion, consider that you need to provide the binaries of cabal, ghc and native dependencies some way! |
| 2021-08-14 17:11:43 | <dminuoso> | perhaps it ought not be listed here. |
| 2021-08-14 17:11:50 | <dminuoso> | since it's, at the end, just plain cabal |
| 2021-08-14 17:11:56 | → | wonko joins (~wjc@62.115.229.50) |
| 2021-08-14 17:12:01 | <sclv> | imho using "actual nix" for everything is either because you like using nix to manage everything else in your dev ecosystem, or because you are at a shop that's using nix for its workflows pervasively |
| 2021-08-14 17:12:14 | <sclv> | for individual projects/libs my experience is nix buys very little |
| 2021-08-14 17:12:22 | <maerwald> | aegon: oh, nix isn't a good fit if you care about vulnerabilities and security fixes |
| 2021-08-14 17:12:26 | <sclv> | but for managing releases/deployments of large multi-component systems it buys a Lot |
| 2021-08-14 17:13:16 | <dminuoso> | Indeed. We are currently building a multi node fleet of about 25 different servers doing different things. A fair chunk of it runs custom haskell code, and there's a lot of coupling and dependencies |
| 2021-08-14 17:13:33 | <dminuoso> | For this type of deployment going all nixos/nix helps a lot staying sane |
| 2021-08-14 17:13:36 | <aegon> | sclv: dminuoso: i'll try switching over a project from stack to the new cabal, do you have a good pointer to docs to freshen up on? |
| 2021-08-14 17:13:50 | <dminuoso> | aegon: cabal has very good documentation |
| 2021-08-14 17:13:56 | <maerwald> | @hackage stack2cabal -- aegon |
| 2021-08-14 17:13:56 | <lambdabot> | https://hackage.haskell.org/package/stack2cabal -- aegon |
| 2021-08-14 17:14:06 | <sclv> | https://cabal.readthedocs.io/en/3.4/nix-local-build-overview.html |
| 2021-08-14 17:14:09 | <monochrom> | Clearly, the decision about nix is very easy. If you already know nix, it's a no-brainer to add "now use it for haskell stuff". If you don't already know nix, clearly it is Bismarck's Nightmare to fight both nix and haskell stuff at the same time. |
| 2021-08-14 17:14:31 | <dminuoso> | monochrom: Indeed, it took me nearly 2 to get a full grasp and handle on nixos and nix. |
| 2021-08-14 17:14:35 | <dminuoso> | 2 years. |
| 2021-08-14 17:14:51 | <dminuoso> | But we didnt have someone in our company to help and train |
| 2021-08-14 17:15:00 | × | wallymathieu quits (~wallymath@81-234-151-21-no94.tbcn.telia.com) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-08-14 17:15:11 | <dminuoso> | Figuring everything out by yourself is incredibly nightmarish |
| 2021-08-14 17:15:12 | <sclv> | yes, we rely heavily on nix at work and i can't imagine what we'd do without it, some ungodly combination of puppet and docker and three other things, i imagine. also i barely understand it at all and rely on our nix-experts to do anything nontrivial :-) |
| 2021-08-14 17:15:22 | <sm> | is there any change Nix-style could be removed and replaced with another term in cabal docs ? It's confusing |
| 2021-08-14 17:15:24 | <sm> | chance |
| 2021-08-14 17:15:33 | <dminuoso> | sm: absolutely, make the proposal? |
| 2021-08-14 17:15:51 | → | Guest74 joins (~Guest74@91-155-110-45.elisa-laajakaista.fi) |
| 2021-08-14 17:15:57 | <sclv> | iirc nobody really likes the name, but there's been no clear far better replacements |
| 2021-08-14 17:16:07 | <maerwald> | sclv: I had the same. The nix guru left and we rewrote in ansible and never looked back, because after all, the problem was advertised more complicated than it actually was :p |
| 2021-08-14 17:16:31 | <dminuoso> | For us, the only alternative would be kubernetes |
| 2021-08-14 17:16:35 | <sclv> | the word "nix" luckily doesn't appear anywhere in the commands and u/x for haskell afaik |
| 2021-08-14 17:16:48 | <sm> | I found https://github.com/haskell/cabal/issues/6105 |
| 2021-08-14 17:16:51 | <dminuoso> | But kubernetes is just as complicated in terms of knowledge needed to absorb |
| 2021-08-14 17:17:08 | → | burnsidesLlama joins (~burnsides@dhcp168-012.wadham.ox.ac.uk) |
| 2021-08-14 17:17:08 | × | Guest74 quits (~Guest74@91-155-110-45.elisa-laajakaista.fi) (Client Quit) |
| 2021-08-14 17:17:14 | <sm> | but v2-build is even worse |
| 2021-08-14 17:17:23 | <maerwald> | whether you have a nix guru or a kubernetes guru... not much difference |
| 2021-08-14 17:17:24 | <sclv> | my feeling is as we rewrite the docs (ongoing) then its a good opportunity to clean that all up, especially since "v2-build" or "nix style build" is just "build" and its really just a term to distinguish from legacy build |
| 2021-08-14 17:17:29 | <maerwald> | except the nix guru might be more expensive |
| 2021-08-14 17:17:38 | <sclv> | so on a long enough timeframe, the right prefix is... none |
| 2021-08-14 17:17:41 | <dsal> | So you're saying nix is more lucrative... |
| 2021-08-14 17:17:48 | <maerwald> | it's more niche |
| 2021-08-14 17:18:04 | <dsal> | I really like nixos as a user, but I haven't really figured out how to do anything useful with nix as a thing. |
| 2021-08-14 17:18:10 | <maerwald> | and nix is heavily oversold |
| 2021-08-14 17:18:15 | <maerwald> | so it can pay well |
| 2021-08-14 17:18:18 | × | wonko quits (~wjc@62.115.229.50) (Ping timeout: 258 seconds) |
| 2021-08-14 17:18:37 | <dminuoso> | Btw, I was very amused when you said |
| 2021-08-14 17:18:39 | <dminuoso> | 18:58:05 maerwald | well, I don't have a strong opinion |
| 2021-08-14 17:18:44 | <dminuoso> | You're one with very strong opinions. :-) |
| 2021-08-14 17:18:47 | <maerwald> | lol |
| 2021-08-14 17:19:02 | <sclv> | who hacked maerwalds account!? |
| 2021-08-14 17:19:17 | <maerwald> | maybe I just like to get roasted? ;-) |
| 2021-08-14 17:20:37 | × | gethuen quits (uid502979@id-502979.stonehaven.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-08-14 17:21:05 | × | vicfred quits (~vicfred@user/vicfred) (Ping timeout: 248 seconds) |
| 2021-08-14 17:21:32 | × | burnsidesLlama quits (~burnsides@dhcp168-012.wadham.ox.ac.uk) (Ping timeout: 252 seconds) |
| 2021-08-14 17:21:40 | <monochrom> | Give a man a fire, and he will be warm for a day. Give a strong opinion, and you will be warm for the rest of your life. |
| 2021-08-14 17:23:19 | <aegon> | the nix-style builds looks like all the same stuff, i need to learn how to run local hoogle in cabal-nix land per project and this seems like an easy switch / way out of resolver land |
| 2021-08-14 17:24:23 | → | pfurla joins (~pfurla@ool-3f8fcb0f.dyn.optonline.net) |
| 2021-08-14 17:24:50 | <dminuoso> | aegon: "nix-style builds" is just a fancy way of saying that cabal since a few years will put build artifacts into a system global store, thereby allowing multiple flavors/versions of a dependency to co-exist. |
| 2021-08-14 17:25:07 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-08-14 17:25:18 | <dminuoso> | This is termed "nix-style" since this was inspired by how nix builds things. |
| 2021-08-14 17:25:35 | <sclv> | aegon: `cabal v2-haddock --haddock-hoogle` should generate the hoogledb? note that v2-haddock in general is not in great shape to be honest. |
| 2021-08-14 17:26:04 | <sclv> | it may have gotten better, but where it ends up stashing stuff is sort of confusing |
| 2021-08-14 17:26:37 | <sclv> | the whole notion of haddocks has a more "global" feel than a lot of other commands, so its a bit more odd in the new paradigm |
| 2021-08-14 17:27:11 | <maerwald[m]> | Imo nix only makes sense if you don't control the environment |
| 2021-08-14 17:27:11 | <dminuoso> | For my uses, `hoogle` on the website against the stackage resolver seems to work fine 95% of the time. :P |
| 2021-08-14 17:27:18 | <sclv> | instead of "nix style" it might be more generic to call these "store-style builds" as opposed to "packagedb-style builds" |
| 2021-08-14 17:27:25 | <sclv> | for some neutral terminology going forward |
| 2021-08-14 17:27:41 | <maerwald[m]> | That's why cardano's daedalus uses nix to set up the wallet and node etc |
| 2021-08-14 17:27:47 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 2021-08-14 17:27:57 | <maerwald[m]> | Because you don't know the users env |
| 2021-08-14 17:28:10 | × | pfurla_ quits (~pfurla@ool-3f8fcb0f.dyn.optonline.net) (Ping timeout: 272 seconds) |
| 2021-08-14 17:28:26 | <maerwald[m]> | If you deploy to your own environments, what's the point |
| 2021-08-14 17:28:27 | <monochrom> | Eventually I wrote https://github.com/treblacy/hasdoc to locate library docs. My script focuses on the index.html's, but perhaps you can adapt it for hoogledb. |
| 2021-08-14 17:30:31 | → | wootehfoot joins (~wootehfoo@user/wootehfoot) |
| 2021-08-14 17:30:43 | <aegon> | yeah i think i need to get into a situtuation where nix solves a problem for me before i grokk it. It feels like a security vulnerability to me at the moment, like flat-pack. seems easy to have some super old libs active on your system and not realize it |
| 2021-08-14 17:31:06 | <maerwald[m]> | Nix wasn't designed around security |
| 2021-08-14 17:31:24 | → | mei joins (~mei@user/mei) |
| 2021-08-14 17:31:29 | <maerwald[m]> | Anything that freezes package versions or does LTS style things isn't |
| 2021-08-14 17:32:18 | × | keutoi quits (~keutoi@223.182.21.173) (Quit: leaving) |
| 2021-08-14 17:32:51 | → | betelgeuse joins (~john2gb@94-225-47-8.access.telenet.be) |
| 2021-08-14 17:32:52 | × | wroathe quits (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 258 seconds) |
| 2021-08-14 17:34:19 | <sm> | to be secure we should pull in new things every time, yup :) |
| 2021-08-14 17:35:09 | <sm> | I feel the optimum must be somewhere in the middle |
| 2021-08-14 17:35:31 | <maerwald[m]> | Yes, reproducible and security are contradicting goals |
| 2021-08-14 17:36:56 | <aegon> | all my bias is from a bad experience fighting lts-like systems in debian with a needed patch to openssl so I'm coming at this from a heavy bias |
| 2021-08-14 17:37:49 | <maerwald[m]> | There's only one universal definition of security and that's about how economic it is for an attacker to find vulnerabilities. And there's only one sure way to increase this cost: always update. Because then attackers have to study new versions |
| 2021-08-14 17:37:49 | <aegon> | don't claim to have good reasoning against lts or reproducablility. in the past its been way easier to test version upgrades vs having to upgrade something baked into a curated lts set of packages |
| 2021-08-14 17:38:19 | <maerwald[m]> | Security backports are not as useful as ppl think |
| 2021-08-14 17:38:44 | <maerwald[m]> | As gregkh put it: it's not even clear what bugfix is a security bugfix and what isn't |
| 2021-08-14 17:38:58 | × | Hanicef quits (~gustaf@81-229-9-108-no92.tbcn.telia.com) (Quit: leaving) |
| 2021-08-14 17:39:16 | <maerwald[m]> | No one has been able to come up with a reasonable distinction that you can apply |
| 2021-08-14 17:39:22 | <maerwald[m]> | So you must assume all bugfixes can affect security |
All times are in UTC.