Logs: liberachat/#haskell
| 2021-08-21 23:55:30 | → | xff0x joins (~xff0x@2001:1a81:5267:2d00:3019:a525:5831:f042) |
| 2021-08-21 23:55:31 | <sclv> | assume you just had a library |
| 2021-08-21 23:55:38 | × | raehik quits (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 250 seconds) |
| 2021-08-21 23:55:42 | <sclv> | if it didn't declare the modules, how would you know what was part of the package? |
| 2021-08-21 23:55:46 | <sclv> | how would any manifest work? |
| 2021-08-21 23:56:06 | <fresheyeball> | it would use the exposed modules |
| 2021-08-21 23:56:16 | <sclv> | but how does it know what's exposed? |
| 2021-08-21 23:56:24 | <fresheyeball> | you would still need to provide exposed-modules |
| 2021-08-21 23:56:26 | <sclv> | the files need to be declared somewhere |
| 2021-08-21 23:56:32 | <fresheyeball> | and it would include the tree of deps that implies |
| 2021-08-21 23:56:44 | <sclv> | ok, so the issue is of course that cabal doesn't know the trace tree of the deps |
| 2021-08-21 23:56:46 | <fresheyeball> | if the build requires a module that is not exposed, it just includes it |
| 2021-08-21 23:56:47 | <sclv> | and nobody else does too |
| 2021-08-21 23:56:56 | <fresheyeball> | well it sure seems to |
| 2021-08-21 23:56:56 | <sclv> | so figuring out "what files are in this package" would require running ghc |
| 2021-08-21 23:57:02 | <fresheyeball> | since it can warn about it |
| 2021-08-21 23:57:08 | <sclv> | that's ghc's warning, not cabals |
| 2021-08-21 23:57:11 | <fresheyeball> | right |
| 2021-08-21 23:57:18 | <fresheyeball> | so... code needs to be written |
| 2021-08-21 23:57:27 | <sclv> | anyway you asked what the point was, and that's the point |
| 2021-08-21 23:57:36 | <fresheyeball> | but nothing to stop ghc's warning to become other-modules automatically behind the scenes |
| 2021-08-21 23:57:37 | → | o1lo01ol1o joins (~o1lo01ol1@5.181.115.89.rev.vodafone.pt) |
| 2021-08-21 23:57:41 | <fresheyeball> | ok |
| 2021-08-21 23:57:44 | <fresheyeball> | so fuck it |
| 2021-08-21 23:57:45 | → | raehik joins (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-08-21 23:57:46 | <sclv> | and also, even if cabal could know from ghc we'd still want a manifest so anyone else could know without running ghc |
| 2021-08-21 23:57:49 | <fresheyeball> | I am goign to ignore this |
| 2021-08-21 23:57:56 | <sm> | hpack can reduce maintenance effort. I don't know if it helps here at all |
| 2021-08-21 23:57:59 | <sclv> | for a test suite you can ignore it |
| 2021-08-21 23:57:59 | <fresheyeball> | I don't want to have to maintain these other-modules lists |
| 2021-08-21 23:58:09 | <sclv> | for the main lib you can't ignore it |
| 2021-08-21 23:58:10 | <fresheyeball> | why is that a special case? |
| 2021-08-21 23:58:20 | <sclv> | because cabal sdist will not produce a proper package |
| 2021-08-21 23:58:25 | <fresheyeball> | omg |
| 2021-08-21 23:58:27 | <sclv> | since it won't gather up all the files |
| 2021-08-21 23:58:34 | <sclv> | since it doesn't know what they are, unless you tell it |
| 2021-08-21 23:58:36 | <fresheyeball> | we have got to fix this |
| 2021-08-21 23:58:48 | <fresheyeball> | this is just annoying busy work for developers that doesn't need to be there |
| 2021-08-21 23:58:49 | <sclv> | the alternative, which is far worse, is that cabal just grabs every stray file in /src |
| 2021-08-21 23:58:56 | <sclv> | we have ides that manage this for you |
| 2021-08-21 23:59:14 | <fresheyeball> | I don't find that satisfying |
| 2021-08-21 23:59:16 | <fresheyeball> | also how? |
| 2021-08-21 23:59:22 | <sclv> | well people wrote them |
| 2021-08-21 23:59:25 | <sclv> | is how we got them |
| 2021-08-21 23:59:39 | → | chris joins (~chris@81.96.113.213) |
| 2021-08-21 23:59:42 | <sm> | less than a real fix, but could Cabal detect and warn about this more clearly ? |
| 2021-08-21 23:59:43 | chris | is now known as Guest9363 |
| 2021-08-21 23:59:46 | <sclv> | anyway my recommendation is that sharing directories like you're doing is entirely not recommended |
| 2021-08-22 00:00:00 | <monochrom> | "cabal sdist" warns. |
| 2021-08-22 00:00:02 | <fresheyeball> | I know |
| 2021-08-22 00:00:11 | <fresheyeball> | but it I don't share directories dev workflow sucks |
| 2021-08-22 00:00:19 | <fresheyeball> | because I can't alter lib files and get an updte |
| 2021-08-22 00:00:24 | <fresheyeball> | I have to restart ghcid |
| 2021-08-22 00:00:31 | <sm> | there's a flag that does it |
| 2021-08-22 00:00:49 | <fresheyeball> | oh! |
| 2021-08-22 00:00:50 | <fresheyeball> | what is it |
| 2021-08-22 00:00:51 | <monochrom> | I know both sides of the argument for and against "modules should be manually listed" "modules should be automatically detected". |
| 2021-08-22 00:01:27 | <sm> | fresheyeball: I'm very sorry, I'm just dimly pattern-matching solutions I've heard about and don't remember |
| 2021-08-22 00:01:40 | × | waleee quits (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) (Ping timeout: 240 seconds) |
| 2021-08-22 00:01:40 | <fresheyeball> | no worries |
| 2021-08-22 00:01:42 | × | jgeerds quits (~jgeerds@55d4b311.access.ecotel.net) (Ping timeout: 245 seconds) |
| 2021-08-22 00:01:56 | <fresheyeball> | I just can't see any argument in favor of manually listing |
| 2021-08-22 00:02:06 | <monochrom> | At the end I am inclined towards the manual side. Besides, a simple "cabal sdist" already alerts you what you haven't listed. |
| 2021-08-22 00:02:09 | <sm> | so what about the hpack idea |
| 2021-08-22 00:02:13 | × | o1lo01ol1o quits (~o1lo01ol1@5.181.115.89.rev.vodafone.pt) (Ping timeout: 252 seconds) |
| 2021-08-22 00:02:15 | <fresheyeball> | it just seems like busy work, and introduces the potential of adding a module that is not used |
| 2021-08-22 00:02:27 | <fresheyeball> | I used to use hpack for this |
| 2021-08-22 00:02:33 | <fresheyeball> | but people got mad at me :( |
| 2021-08-22 00:02:36 | <fresheyeball> | so I go back to cabal |
| 2021-08-22 00:02:48 | <sclv> | we do have a ticket for wildcards in cabal, but its currently blocked on the exact-print work. https://github.com/haskell/cabal/issues/5343 the good news is the exact-print work is underway for the next cabal release |
| 2021-08-22 00:02:49 | <sm> | commit your cabal file, then there's no reason for anyone to get mad |
| 2021-08-22 00:03:05 | <monochrom> | hpack doesn't seem to generate version bounds, last I heard from a user question. That will cause some other problems. |
| 2021-08-22 00:03:39 | <sm> | I think that's not hpack's job, it just translates what you wrote in package.yaml |
| 2021-08-22 00:04:01 | <sm> | there you can go wild with bounds, hpack has no opinion |
| 2021-08-22 00:04:23 | <monochrom> | What is hpack's job? What is its use case? I mean if not for making something reasonably usable by a cabal-and-hackage user. |
| 2021-08-22 00:04:48 | <sclv> | its job is just "you can write cabal files but use more braces in your syntax, if you like braces, dude" |
| 2021-08-22 00:04:49 | <monochrom> | Without version bounds, a *.cabal file is immediately unusable in the context of hackage. |
| 2021-08-22 00:04:53 | <sm> | it's pretty clear from the README IIRC ? I don't want to answer hastily and wrongly |
| 2021-08-22 00:05:58 | <sm> | it lets you generate cabal files from a simpler and less redundant format, saving some work and for certain projects, removing a big source of errors (forgetting to mirror changes in all components, forgetting to declare new files, etc.) |
| 2021-08-22 00:06:19 | <sclv> | common stanzas in cabal for the most part eliminated the "less redundant" bit |
| 2021-08-22 00:06:37 | <sclv> | but in fairness to hpack those are much more recent than hpac |
| 2021-08-22 00:06:46 | <sm> | yes, that's true nowadays, if you can require your builders to have a new-enough cabal-install |
| 2021-08-22 00:07:26 | → | Guest82 joins (~Guest82@p1256008-ipoe.ipoe.ocn.ne.jp) |
| 2021-08-22 00:08:03 | <fresheyeball> | sclv: if I use -fno-warn-home-modules |
| 2021-08-22 00:08:04 | <sm> | also, what's this about braces ? I have no braces in my package.yamls |
| 2021-08-22 00:08:06 | <fresheyeball> | on the exes |
| 2021-08-22 00:08:14 | <fresheyeball> | will cabal make too big of binaries? |
| 2021-08-22 00:08:30 | <monochrom> | The *.cabal file format doesn't require braces either. |
| 2021-08-22 00:09:09 | <monochrom> | Whoever talked about braces, I don't know what they're talking about, I think they don't know either. Unless the FUD hypothesis is true. |
| 2021-08-22 00:09:28 | <sm> | ok, package.yaml and .cabal are dead even on the braces issue. :) |
| 2021-08-22 00:09:55 | <monochrom> | I am not thrilled about YAML in general. |
| 2021-08-22 00:10:21 | <fresheyeball> | yaml is... better that this batshit snowflake .cabal syntax |
| 2021-08-22 00:10:34 | × | Guest82 quits (~Guest82@p1256008-ipoe.ipoe.ocn.ne.jp) (Client Quit) |
| 2021-08-22 00:10:45 | <fresheyeball> | hell I would take toml |
| 2021-08-22 00:10:50 | <fresheyeball> | and I do not like yaml or toml |
| 2021-08-22 00:11:20 | <monochrom> | YAML did not exist when .cabal needed some kind of syntax. |
| 2021-08-22 00:11:37 | <monochrom> | At that time the other choice was XML. |
| 2021-08-22 00:12:07 | <fresheyeball> | I don't fault the old gods for their choices |
| 2021-08-22 00:12:13 | <fresheyeball> | but I would have like hpack to take over |
| 2021-08-22 00:12:20 | <fresheyeball> | and get us out of snowflake land |
All times are in UTC.