Oleg Grenrus

I’m sorry to interrupt but I veto any cli changes to `cabal install —lib` interface until there is a clear plan for the final UI. I have opened various issues...

That is a good question. Yet adding more debt and implementing not so well-thought out ideas is kind of the way we got here in the first place. install —lib...

> But the problem with a squash-and-merge workflow is that it tends to promote the abuse-commits-as-save-button symptom I lament which are tedious to review IMO I agree 100%. Let's not...

Accidental upload is why e.g. `cabal` have changed to upload candidates by default. I'd be ok to require human click to publish packages. (`amazonka` monster uploads is a bit of...

Note: solver is free to pick up deprecated packages! it's a soft preference. To "completely" prevent a package version from being used, you'd need to make a revision with unsatisfiable...

Two forgotten things in this discussion: **First:** JSON / YAML / ... and even Dhall would still need some stringly sublanguages, as @Ericson2314 hints. Consider `build-depends` or `mixins` fields. ```cabal...

> Having an outer YAML syntax would still allow third-party tools easy access to certain contents of the .cabal file, and nice syntax (that is, the current syntax) for constraints...

That's the old problem of `Cabal` library being both the package description reading library as well as its interpration i.e. building. Former part barely changes (except of normal "let's make...

Similarly, we should error for ``` cabal --require-sandbox v2-build ```

FWIW, adding of conditionals with `build-depends` which don't add new dependencies has already have been discussed, I don't remember whether my and Herbert discussions are recorded though. Maybe in `hackage-cli`...