Logs: freenode/#haskell
| 2021-05-04 11:27:01 | → | ddellacosta joins (ddellacost@gateway/vpn/mullvad/ddellacosta) |
| 2021-05-04 11:27:37 | <merijn> | cub3s_: Depends, was your cabal experience with v1-build or v2-build? Because those are *very* different experiences :p |
| 2021-05-04 11:27:41 | <maerwald> | merijn: cabal doesn't solve the problem sufficiently where you have many inter-dependent teams and projects that have different release schedules etc |
| 2021-05-04 11:27:52 | <maerwald> | with stack you can say all of them use the same resolver |
| 2021-05-04 11:28:01 | <maerwald> | you can't have a remote freeze file, for instance |
| 2021-05-04 11:28:04 | <merijn> | maerwald: Sure, I'm not saying it solves every issue |
| 2021-05-04 11:28:06 | × | esp392892 quits (~esp32_pro@89.45.7.186) (Ping timeout: 260 seconds) |
| 2021-05-04 11:28:27 | <merijn> | but also, not everyone is working in teams/setups like that |
| 2021-05-04 11:28:37 | <Arahael> | maerwald: Incidentially, I found using stack with nix quite dificult, even though stack ostensibly supports nix. |
| 2021-05-04 11:28:41 | <cub3s_> | merijn, probably v1 some years ago. honestly that must have been the reason we started using stack in the first place? hmm. |
| 2021-05-04 11:28:48 | <merijn> | cub3s_: Probably |
| 2021-05-04 11:29:33 | <merijn> | cub3s_: v2-build didn't get released until 2016 and wasn't the default until cabal 3.0, which is from...2019 |
| 2021-05-04 11:29:42 | → | esp32_prog joins (~esp32_pro@89.45.7.186) |
| 2021-05-04 11:29:53 | <merijn> | cub3s_: So if you haven't used it, it's certainly worth trying again :) |
| 2021-05-04 11:29:56 | × | tsteeples quits (~steeps@cpc121168-oxfd27-2-0-cust161.4-3.cable.virginm.net) (Quit: Leaving) |
| 2021-05-04 11:30:03 | → | ccapndave joins (~ccapndave@213.55.220.91) |
| 2021-05-04 11:30:07 | <cub3s_> | wow ok, very recent! ok yes i indeed remember "dangerous reinstall" lol |
| 2021-05-04 11:30:13 | <merijn> | cub3s_: Oh yeah |
| 2021-05-04 11:30:22 | <merijn> | cub3s_: That's from the era of pain :p |
| 2021-05-04 11:30:27 | <cub3s_> | ok, so wow... maybe stack/nixpkgs are now obsolete! |
| 2021-05-04 11:30:28 | <merijn> | cub3s_: It's incomparable with now |
| 2021-05-04 11:30:55 | → | nicholasbulka joins (~nicholasb@2601:900:4301:da0:4851:1ff9:a46:9389) |
| 2021-05-04 11:31:12 | <ccapndave> | Hey everyone - I am trying to upgrade my Haskell platform (because I haven't used it for ages and am about to start a course). I've installed gchup and everything looks fine, but I seem to have `~/.cabal.bin` in my PATH and I have absolutely no idea how its getting there. This is on MacOS with zsh. Does anyone have a clue where the path might be being set? |
| 2021-05-04 11:31:15 | <merijn> | cub3s_: v2-build allows infintely parallel installs of the same package. Nix-inspired (every install tagged with hash of build flags and transitive dependencies) |
| 2021-05-04 11:31:23 | <ccapndave> | Its not in `.zshrc`, `/etc/profile` or `/etc/zprofile` |
| 2021-05-04 11:31:41 | × | ddellacosta quits (ddellacost@gateway/vpn/mullvad/ddellacosta) (Ping timeout: 240 seconds) |
| 2021-05-04 11:31:45 | <cub3s_> | wow how did i not know about this... :S |
| 2021-05-04 11:31:48 | <Arahael> | merijn: Very nice! |
| 2021-05-04 11:31:48 | <cub3s_> | nix propaganda?? |
| 2021-05-04 11:31:51 | <merijn> | cub3s_: When you build it computes a build-plan, and then dynamically exposes only the relevant installed packages for the build, so you no longer get conflicts between different projects on the same machine |
| 2021-05-04 11:32:35 | <merijn> | cub3s_: Also massive improvements like "if you do a profiling build, it will just install missing profiling dependencies without breaking everything" :p |
| 2021-05-04 11:33:15 | × | ericsagnes quits (~ericsagne@2405:6580:0:5100:4bd1:656f:4270:d212) (Ping timeout: 260 seconds) |
| 2021-05-04 11:33:16 | <merijn> | cub3s_: Like I said, I like Nix *the idea* I just don't like the execution :p v2-build is the same idea (although limited to Haskell packages) |
| 2021-05-04 11:33:37 | <merijn> | cub3s_: See also: https://cabal.readthedocs.io/en/latest/nix-local-build-overview.html (although note that the v2- prefix is optional in 3.0 and later) |
| 2021-05-04 11:33:48 | → | carlomagno joins (~cararell@148.87.23.13) |
| 2021-05-04 11:34:00 | <merijn> | Since it's now the default |
| 2021-05-04 11:34:06 | <Arahael> | merijn: And I expect v2-build has a fighting chance of actually working on windows. |
| 2021-05-04 11:34:18 | <Arahael> | I used to use nix on my mac, but I haven't for over two years. |
| 2021-05-04 11:34:31 | <Arahael> | (It's just a super massive PITA on the mac, and you can't run "pure" anyway) |
| 2021-05-04 11:35:11 | × | nicholasbulka quits (~nicholasb@2601:900:4301:da0:4851:1ff9:a46:9389) (Ping timeout: 250 seconds) |
| 2021-05-04 11:35:52 | <maerwald> | everything is a PITA on mac |
| 2021-05-04 11:36:38 | Arahael | twitches |
| 2021-05-04 11:36:39 | <merijn> | cub3s_: It doesn't solve issue with system/C package management and issues of "there is no buildplan", but with v2-build *if* there is a working buildplan it builds, which definitely wasn't the case in the "dangerous reinstall" era :p |
| 2021-05-04 11:36:40 | <cub3s_> | yes i've abandoned mac because of it |
| 2021-05-04 11:37:23 | <cub3s_> | merijn, for me these non-haskell dependencies are usually just a few apt install commands |
| 2021-05-04 11:37:48 | <cub3s_> | that cabal documentation is nice! |
| 2021-05-04 11:38:36 | × | dinciorip quits (~dincio@5.171.9.145) (Ping timeout: 260 seconds) |
| 2021-05-04 11:38:45 | <cub3s_> | "if b has a loose dependency on c such that it may bump a major version, or if the developer of c does not respect semver. a may cause c to be updated to a point where b does not work. Alternatively b may cause c to be held to a lower version than what a is expecting (because there was a bug fix in a minor version which b does not depend on) Now b will build with old c but a will fail. These are the issues with Cabal" |
| 2021-05-04 11:38:49 | <cub3s_> | https://medium.com/@edmundnoble/cabal-or-stack-25886c0ac74f |
| 2021-05-04 11:38:55 | <cub3s_> | does v2 solve this? |
| 2021-05-04 11:39:22 | <maerwald> | I use stackage with cabak |
| 2021-05-04 11:39:26 | <maerwald> | *cabal |
| 2021-05-04 11:39:54 | <merijn> | cub3s_: No*, but Hackage supports revisions to retroactively apply upperbounds and unbreak build plans in these scenarios |
| 2021-05-04 11:40:16 | <merijn> | cub3s_: You can also generate freeze files, that preserve the current buildplan exactly |
| 2021-05-04 11:40:24 | <maerwald> | yeah, revisons are awful |
| 2021-05-04 11:40:35 | → | dinciorip joins (~dincio@5.171.9.137) |
| 2021-05-04 11:40:48 | <merijn> | maerwald: revisions are a necessary evil as long as people insist on shitty upperbound hygiene |
| 2021-05-04 11:41:21 | <cub3s_> | maerwald, you mean you use cabal with stackage instead of hackage, but don't use the "stack" tool? |
| 2021-05-04 11:41:23 | <merijn> | cub3s_: Tangentially related, but many people don't know it exists: https://pvp.haskell.org/ |
| 2021-05-04 11:41:45 | <merijn> | cub3s_: stackage is, effectively, just a freeze file of specific versions of packages |
| 2021-05-04 11:41:58 | <merijn> | cub3s_: You can generate constraints from that and feed them to cabal-install |
| 2021-05-04 11:42:06 | <maerwald> | merijn: no, they are not necessary. You can bump the version when fixing package metadata. It's also the fault of PVP for not having revisions |
| 2021-05-04 11:42:06 | <merijn> | And get the same behaviour |
| 2021-05-04 11:42:24 | → | geowiesnot joins (~user@87-89-181-157.abo.bbox.fr) |
| 2021-05-04 11:42:27 | <maerwald> | so to fix one mistake, they made another |
| 2021-05-04 11:42:45 | <maerwald> | now revisions are an infrastructure specific API |
| 2021-05-04 11:42:49 | <merijn> | maerwald: How do you propose filtering the old, broken, version from buildplans? |
| 2021-05-04 11:43:13 | <maerwald> | merijn: what do you mean? |
| 2021-05-04 11:43:29 | <merijn> | cub3s_: Also related: https://gist.github.com/merijn/8152d561fb8b011f9313c48d876ceb07 |
| 2021-05-04 11:43:47 | <merijn> | maerwald: Suppose foo-1.0.0 is released with no upperbound on bar, which breaks when bar is released |
| 2021-05-04 11:44:10 | <merijn> | maerwald: How do I make sure the build-plan doesn't include foo-1.0.0 with the incompatible version of bar |
| 2021-05-04 11:44:29 | <maerwald> | you release foo-1.0.1 |
| 2021-05-04 11:44:39 | <merijn> | maerwald: That doesn't fix anything |
| 2021-05-04 11:44:43 | <maerwald> | it does |
| 2021-05-04 11:44:49 | <merijn> | maerwald: The solver still sees foo-1.0.0 and can't know its broken |
| 2021-05-04 11:45:09 | → | mud joins (~mud@unaffiliated/kadoban) |
| 2021-05-04 11:45:14 | <merijn> | So the solver will still find buildplans using the broken -1.0.0 |
| 2021-05-04 11:45:26 | <maerwald> | why would it? |
| 2021-05-04 11:45:42 | <merijn> | You need to somehow tell the solver it cannot use foo-1.0.0 with bar X *or* remove foo-1.0.0 from the index (potentially breaking a lot more) |
| 2021-05-04 11:45:53 | <merijn> | maerwald: Ok, let me sketch a scenario |
| 2021-05-04 11:46:01 | <maerwald> | yes, broken versions can be removed |
| 2021-05-04 11:46:05 | <maerwald> | that's what distros do |
| 2021-05-04 11:46:09 | <maerwald> | all solved problems |
| 2021-05-04 11:46:16 | <merijn> | maerwald: That is much more work |
| 2021-05-04 11:46:25 | × | ccapndave quits (~ccapndave@213.55.220.91) () |
| 2021-05-04 11:46:30 | <maerwald> | I think most of the time you don't need it |
| 2021-05-04 11:46:33 | <merijn> | maerwald: Because now *everything* transitively depending on foo needs a new release |
| 2021-05-04 11:46:34 | <maerwald> | cargo also works without it |
| 2021-05-04 11:46:46 | → | ericsagnes joins (~ericsagne@2405:6580:0:5100:a104:d14:93ae:b6b0) |
| 2021-05-04 11:47:15 | × | todda7 quits (~torstein@2a02:587:3724:1a75:aca:df22:9d82:969f) (Ping timeout: 260 seconds) |
| 2021-05-04 11:47:23 | <maerwald> | merijn: what? |
| 2021-05-04 11:49:12 | × | geowiesnot quits (~user@87-89-181-157.abo.bbox.fr) (Ping timeout: 240 seconds) |
| 2021-05-04 11:50:07 | <merijn> | foo-1.0.0 depends on bar, but without an upperbound. A new release, bar-2.0 comes out and breaks foo-1.0.0 due to foo not having an upperbound on bar. My package quux depends on: "foo == 1.0.0, bar >= 0.5 && < 2.1" The solver sees "foo-1.0.0" works with all versions of bar and sees "bar-2.0" so it generates that buildplan. Now things are broken, because foo-1.0.0 doesn't compile with bar-2.0. The solution |
| 2021-05-04 11:50:13 | <merijn> | with revision is to update the upperbound of foo to exclude the (broken) bar-2.0, and then everything works |
| 2021-05-04 11:50:46 | <maerwald> | merijn: ah, your problem... don't depend on == 1.0.0, use PVP upper bounds |
| 2021-05-04 11:50:58 | <maerwald> | the only reason you would do == is freeze files |
| 2021-05-04 11:51:04 | <merijn> | maerwald: Hackage has 10,000s of packages doing all sorts of stupid stuff |
| 2021-05-04 11:51:16 | <merijn> | maerwald: Your solution would break tons of them |
| 2021-05-04 11:51:16 | <maerwald> | and then you already have a working build plan and have bar fixed |
| 2021-05-04 11:51:27 | × | nut quits (~nut@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) (Ping timeout: 268 seconds) |
All times are in UTC.