Logs: freenode/#haskell
| 2020-10-06 22:03:45 | → | snakemas1 joins (~snakemast@213.100.206.23) |
| 2020-10-06 22:04:12 | → | worc3131 joins (~quassel@2a02:c7f:c026:9500:7d0b:65d0:38a4:4786) |
| 2020-10-06 22:05:10 | → | Rudd0 joins (~Rudd0@185.189.115.103) |
| 2020-10-06 22:05:26 | × | urdh quits (~urdh@unaffiliated/urdh) (Ping timeout: 256 seconds) |
| 2020-10-06 22:06:31 | → | urdh joins (~urdh@unaffiliated/urdh) |
| 2020-10-06 22:08:04 | × | Vq quits (~vq@90-227-195-41-no77.tbcn.telia.com) (Ping timeout: 246 seconds) |
| 2020-10-06 22:08:25 | → | Stanley00 joins (~stanley00@unaffiliated/stanley00) |
| 2020-10-06 22:09:02 | <orzo> | what's the best practice for switching cabal between ghc versions? |
| 2020-10-06 22:09:13 | <orzo> | i think i should have an independent dist folder |
| 2020-10-06 22:09:25 | <orzo> | but this .freeze thing clearly needs to be duplicated too |
| 2020-10-06 22:09:28 | × | snakemas1 quits (~snakemast@213.100.206.23) (Ping timeout: 272 seconds) |
| 2020-10-06 22:09:41 | <monochrom> | If it is a temp or frequent change, without any meaningful default, "-w ghc-9.4" |
| 2020-10-06 22:09:56 | → | Vq joins (~vq@90-227-195-41-no77.tbcn.telia.com) |
| 2020-10-06 22:10:10 | <orzo> | well i have basically 2 versions i would like to test with |
| 2020-10-06 22:10:22 | <orzo> | and i don't want to have to rebuild everything when i switch |
| 2020-10-06 22:10:31 | <orzo> | assuming it was built before with the other version |
| 2020-10-06 22:11:35 | <orzo> | even if cabal has some higene in the dist folder, i'd have more peice of mind separating it so i could nuke one without impacting the other |
| 2020-10-06 22:12:10 | <monochrom> | Perhaps the --builddir= option helps you? |
| 2020-10-06 22:13:24 | <orzo> | yeah |
| 2020-10-06 22:13:26 | × | Kaeipi quits (~Kaiepi@nwcsnbsc03w-47-55-225-82.dhcp-dynamic.fibreop.nb.bellaliant.net) (Remote host closed the connection) |
| 2020-10-06 22:13:34 | × | conal quits (~conal@209.58.130.230) (Quit: Computer has gone to sleep.) |
| 2020-10-06 22:13:36 | × | Stanley00 quits (~stanley00@unaffiliated/stanley00) (Ping timeout: 260 seconds) |
| 2020-10-06 22:13:39 | <orzo> | there's probably no equivelent for .freeze though is there? |
| 2020-10-06 22:13:47 | → | Kaeipi joins (~Kaiepi@nwcsnbsc03w-47-55-225-82.dhcp-dynamic.fibreop.nb.bellaliant.net) |
| 2020-10-06 22:14:03 | <orzo> | it's not in the builddir but it is strongly associated |
| 2020-10-06 22:14:20 | <orzo> | i guess i'll need to manually rename it when i switch |
| 2020-10-06 22:14:25 | × | alp quits (~alp@2a01:e0a:58b:4920:11c4:1b60:3a4e:bcb2) (Ping timeout: 272 seconds) |
| 2020-10-06 22:14:47 | <sm[m]> | re orzo's original q - does cabal always install the latest version of a package even if there's a good-enough version already installed ? I thought it didn't |
| 2020-10-06 22:15:14 | <orzo> | it probably checks the hackage index |
| 2020-10-06 22:15:16 | × | cosimone quits (~cosimone@2001:b07:ae5:db26:b248:7aff:feea:34b6) (Quit: cosimone) |
| 2020-10-06 22:15:23 | <sm[m]> | ie orzo's intuition about path of least effort sounded correct |
| 2020-10-06 22:15:29 | <orzo> | i used it for a long time without even downloading and updating that so i didn't realize it behaved this way |
| 2020-10-06 22:15:36 | <sclv> | the build dirs are kept by version |
| 2020-10-06 22:15:38 | <sclv> | of ghc |
| 2020-10-06 22:15:57 | <sclv> | so it won't rebuild more than necessary when you pass different -w flags |
| 2020-10-06 22:16:00 | <sm[m]> | oh, you upgraded ghc since then perhaps orzo |
| 2020-10-06 22:17:06 | → | conal joins (~conal@209.58.130.230) |
| 2020-10-06 22:17:33 | <orzo> | i think the least-effort way makes the most sense for the user, but the new way probably has benifits for the community/eco-system since it makes it more likely maintainers will build against newer libs |
| 2020-10-06 22:17:59 | <ski> | koz_ : also `let's in list comprehensions don't have `in'. (and (toplevel) `let's in the interactor) |
| 2020-10-06 22:18:21 | <sm[m]> | least effort is what it still does I believe |
| 2020-10-06 22:18:25 | → | cosimone joins (~cosimone@2001:b07:ae5:db26:b248:7aff:feea:34b6) |
| 2020-10-06 22:18:33 | <orzo> | not so |
| 2020-10-06 22:18:41 | <orzo> | re me&monochrome's discussion |
| 2020-10-06 22:18:44 | <orzo> | i needed the .freeze file |
| 2020-10-06 22:18:51 | <orzo> | i need to manually edit it |
| 2020-10-06 22:18:57 | <orzo> | the build worked fine |
| 2020-10-06 22:19:04 | <orzo> | after i did so |
| 2020-10-06 22:19:26 | <sm[m]> | I think ordinarily it will use an installed version if it can. There are lots of reasons it may think it can't use it |
| 2020-10-06 22:19:32 | × | oisdk quits (~oisdk@2001:bb6:3329:d100:c982:e387:7052:58be) (Quit: oisdk) |
| 2020-10-06 22:19:41 | <sm[m]> | such as a ghc upgrade ? |
| 2020-10-06 22:19:43 | <orzo> | i think it must be just using the latest if it can |
| 2020-10-06 22:19:52 | <orzo> | i did not upgrade ghc |
| 2020-10-06 22:19:55 | <monochrom> | OK, I need to actually test it. |
| 2020-10-06 22:19:55 | × | cosimone quits (~cosimone@2001:b07:ae5:db26:b248:7aff:feea:34b6) (Client Quit) |
| 2020-10-06 22:20:13 | <sm[m]> | ok. I was hoping the cabal gods would pronounce on this |
| 2020-10-06 22:20:39 | <sclv> | new-build always calculates a fresh build plan |
| 2020-10-06 22:20:47 | <sclv> | from the latest version of the hackage index it has around |
| 2020-10-06 22:20:56 | <sm[m]> | wow |
| 2020-10-06 22:20:57 | <sclv> | but unless you `cabal update` you don't refresh your indexx |
| 2020-10-06 22:21:19 | <sclv> | and `cabal update` tells you how to pin to an index snapshot if you want to not recalc |
| 2020-10-06 22:21:39 | <sm[m]> | cabal really doesn't prioritise repeatable builds by default does it |
| 2020-10-06 22:22:00 | <sclv> | it gives lots of tools for getting them, but it defaults to not having them |
| 2020-10-06 22:22:02 | <orzo> | actually the .freeze makes it more repeatable, not less |
| 2020-10-06 22:22:09 | × | twanvl quits (~twanvl@77.165.89.227) (Read error: Connection reset by peer) |
| 2020-10-06 22:22:11 | <orzo> | as it makes it more explicitly configured |
| 2020-10-06 22:22:19 | <sm[m]> | nod |
| 2020-10-06 22:23:43 | <sm[m]> | personally I think repeatability should be the priority for the default, with adventurous new build plans as a power use option |
| 2020-10-06 22:23:46 | <orzo> | sclv, shouldn't the installed deps take precedence over available-in-index deps? |
| 2020-10-06 22:24:22 | <sclv> | its very hard to say what the "best" install plan is given trying to use installed deps |
| 2020-10-06 22:24:40 | <sclv> | you have to explore every possible path to see which uses the greatest percentage of them or whatever |
| 2020-10-06 22:24:51 | <sclv> | its not a straightforward optimization compared to the normal solver |
| 2020-10-06 22:25:12 | <sclv> | and the payoff isnt very clear -- calculating from scratch is an easier behavior to explain and understand |
| 2020-10-06 22:25:40 | <orzo> | it could just do what i did but automatically |
| 2020-10-06 22:26:08 | <sclv> | like auto-freeze on the first run? |
| 2020-10-06 22:26:10 | <orzo> | which is to just look for installed versions of things its trying to download and freeze them to the insalled version |
| 2020-10-06 22:26:32 | <sclv> | that isn't so simple to automate -- what if those installed versions are incompat |
| 2020-10-06 22:26:33 | → | Buntspecht joins (~user@unaffiliated/siracusa) |
| 2020-10-06 22:26:44 | <orzo> | it should be an either or thing |
| 2020-10-06 22:26:49 | <sclv> | or some are incompat with some and you have to pick the bigger set |
| 2020-10-06 22:27:06 | <orzo> | either it can use installed versions in every case, or it falls back to downloading according to the index build plan |
| 2020-10-06 22:27:09 | <sclv> | there's a big design space, and again, its not clear what advantage if any therre is |
| 2020-10-06 22:27:40 | <sclv> | that's certainly one behavior, but i doubt its the only one people would like, or even thee one most people would expect or like |
| 2020-10-06 22:28:15 | <sm[m]> | cabal could act more like stack - leaning on the tested stackage snapshots for repeatability, where it makes sense |
| 2020-10-06 22:28:26 | <sm[m]> | <blue sky> |
| 2020-10-06 22:28:29 | <unclechu> | hi. a question about `lens` package. imagine a have complex lens like this one: `_2._Just._3._Just._2._Right .~ 200`. |
| 2020-10-06 22:28:29 | <unclechu> | in case something cannot be reached (like some of these points was `Nothing` or `Left`) can i have `Maybe` or `Either` wrap which would tell me whether something was changed or not? |
| 2020-10-06 22:28:30 | <unclechu> | to be more precise whether something was *able to change* (whole path was reachable) |
| 2020-10-06 22:29:53 | <orzo> | actually, the behavior i think people would want is a --no-download option that completely disabled network operation |
| 2020-10-06 22:29:54 | → | seanvert joins (~user@177.84.244.242) |
| 2020-10-06 22:30:09 | <yushyin> | You can pin the index you can also use stackage package constrains with cabal if you like. |
| 2020-10-06 22:30:15 | × | LKoen quits (~LKoen@81.255.219.130) (Quit: “It’s only logical. First you learn to talk, then you learn to think. Too bad it’s not the other way round.”) |
| 2020-10-06 22:30:32 | <orzo> | is pinning the index a per-package thing? |
| 2020-10-06 22:30:36 | <orzo> | per-project |
| 2020-10-06 22:30:37 | <orzo> | i mean |
| 2020-10-06 22:30:55 | <sclv> | yes you can put it in the project fil |
| 2020-10-06 22:30:57 | <sclv> | file |
| 2020-10-06 22:31:02 | <unclechu> | instead of having `smth` type i would have either `Maybe smth` where `Just` means that a value was successfully updated or `Either smth smth` where `Left` means that a value couldn’t be updated |
| 2020-10-06 22:31:32 | <monochrom> | https://cabal.readthedocs.io/en/3.4/cabal-project.html#cfg-field-index-state |
| 2020-10-06 22:32:11 | <yushyin> | https://www.stackage.org/lts-16.17/cabal.config :P |
| 2020-10-06 22:32:31 | <dminuoso> | unclechu: My instint says it's unlikely to exist. |
All times are in UTC.