Re: plan.json documentation

A short answer: Look how cabal-docspec is implemented. It does do what you want (i.e. finds all source files) to do its job too. A slightly longer version: - cabal-plan library parses plan.json, its types tell you what is there [1] - plan doesn't include location of .cabal files directly, but it h

Re: [RFC] Qualified module renamings

How this will work with packages adding modules. For concrete example: - parsec-backpack-0.1 provides two modules Parsec.Prim and Parsec.Combinators - in my library, I instantiate Parsec.* to Parsec.Text.*, and Parsec.String.*, I get four modules. That is nice. - parsec-backpack-0.1.1 is released

Re: RFC: A plan to gradual removal of v1- commands

theoretically? On 27.9.2020 17.18, Oleg Grenrus wrote: > Dear development aware cabal users > > I request you to comment on a plan to gradually remove `v1-` commands. > > Some users have commented about the notice in `v1-` commands' `--help`: > >   It is a legacy feat

cabal-install-3.4.0.0-rc4 and Cabal-3.4.0.0-rc4 are now available

The Cabal developers are happy to announce the fourth (and hopefully final) release candidate for cabal-install-3.4.0.0 The corresponding tags are `cabal-install-3.4.0.0-rc4` and `Cabal-3.4.0.0-rc4`     https://github.com/haskell/cabal/releases/tag/cabal-install-3.4.0.0-rc4     https://github.com

Re: RFC: A plan to gradual removal of v1- commands

I forgot to mention. Discussion open until the end of October 2020, that is roughly five weeks. - Oleg On 27.9.2020 17.18, Oleg Grenrus wrote: > Dear development aware cabal users > > I request you to comment on a plan to gradually remove `v1-` commands. > > Some users have comm

RFC: A plan to gradual removal of v1- commands

Dear development aware cabal users I request you to comment on a plan to gradually remove `v1-` commands. Some users have commented about the notice in `v1-` commands' `--help`:   It is a legacy feature and will be removed in a future release of   cabal-install. Please file a bug if you cannot r

cabal-install-3.4.0.0-rc3 and Cabal-3.4.0.0-rc3 are now available

The Cabal developers are happy to announce the third release candidate for cabal-install-3.4.0.0 The corresponding tag are `cabal-install-3.4.0.0-rc3` and `Cabal-3.4.0.0-rc3`     https://github.com/haskell/cabal/releases/tag/cabal-install-3.4.0.0-rc3     https://github.com/haskell/cabal/releases/

cabal-install-3.4.0.0-rc2 and Cabal-3.4.0.0-rc2 are now available

The Cabal developers are happy to announce the first release candidate for cabal-install-3.4.0.0 The corresponding tag are `cabal-install-3.4.0.0-rc2` and `Cabal-3.4.0.0-rc2`     https://github.com/haskell/cabal/releases/tag/cabal-install-3.4.0.0-rc2     https://github.com/haskell/cabal/releases/

cabal-install-3.4-rc1 now available

at: https://github.com/haskell/cabal/tree/master/release-notes Please do test this release and let us know if you encounter any issues: https://github.com/haskell/cabal/issues On 25.7.2020 13.07, Oleg Grenrus wrote: > Dear all, > > Last week I tagged Cabal-3.4 release candidate. After f

Cabal-3.4 release candidate 1

Dear all, Last week I tagged Cabal-3.4 release candidate. After fixing few immediately obvious issues with cabal-install, I have successfully used it for a week. This week I have been working on improving scripts for bootstrapping and release packaging, and as intermediate result there are - x86

Release 3.4 planning

Dear cabal developers and users As GHC-8.12 release plan was announced [1]. I suggest that we cut the 3.4 branch at the end of June, i.e. after the first GHC-8.12 alpha release. I opened an issue for discussion: [2] https://github.com/haskell/cabal/issues/6757 --- I renamed previously existin

Re: Installation failed

e does exist, it may contain errors that are caught by the C compiler at the preprocessing stage. In this case you can re-run configure with the verbosity flag -v3 to see the error messages. cabal: Failed to build digest-0.0.1.2 (which is required by cabal-install-2.4.1.0). See the build log above

Re: Cabal install

linux-8.9.0.20190414 x86_64-linux-8.9.0.20190508 x86_64-linux-8.6.4  x86_64-linux-8.9.0.20190430 x86_64-linux-8.9.0.20190527 bash$ ls ~/.ghc/x86_64-linux-8.6.4/ package.conf.d Simon *From:*Oleg Grenrus *Sent:* 30 May 2019 20:19 *To:* Simon Peyton Jones ; cabal-devel@haskell.org *Subject:* R

Re: Installation failed

Hi again Simon, Few points, If you run Windows 10 (Pro?), you can setup to make symlinks without needing administrator privileges. I used https://github.com/git-for-windows/git/wiki/Symbolic-Links guide. Unfortunately I don't remember all the details I did (i.e. if the guide is complete), but

Re: Cabal install

Hi Simon, my first guess is that: when working on the unsaturated type families paper, you did `cabal install --lib report`; or something similar. `report` is probably some internal library to that paper / project. In that case, you are hitting the unfortunate cabal bug [1]. To confirm, chec

Re: Upgrading Stack to Cabal 2.2

> I ended up with > >     display . either licenseFromSPDX id > > Is it intentional that there is no Text instance for SPDX.License? > > On Tue, Feb 20, 2018 at 8:02 PM, Oleg Grenrus <mailto:oleg.gren...@iki.fi>> wrote: > > 1. The InstalledPackageInfo license field

Re: Upgrading Stack to Cabal 2.2

d storing as Right? > 2. If we're going to have to treat this as arbitrary text anyway, is > there any reason not to represent it as `newtype TextualLicense = > TextualLicense Text` or similar, and convert immediately with `display`? > > On Tue, Feb 20, 2018 at 6:12 PM, Oleg Grenr

Re: Upgrading Stack to Cabal 2.2

Hi Michael, thanks for your comments! - The allBuildInfo change is https://github.com/haskell/cabal/commit/8fc10320a5dc4898927c84ad6a2dce7965ef30db, I agree with Herbert on this. New `allBuildInfo` implementation is correct given the name. There was even a TODO to make that change. `reallyAllBuil

Re: Gearing up for the 2.2 release

I had a good success with completing a lot of parser work around Christmas, still on my todo list are: - rewriting InstalledPackageInfo parser&printer using new (parsec) framework, which is (soft) prerequisite to - changing license field to use SPDX expressions SPDX types are already merged, so

Re: mutex-flags

Hi, I proposed multiway flags about a year ago [1]. With that you could write: flag xx values: a, b, c, d if flag(xx == a) build-depends: xx-a if flag(xx == b) build-depends: xx-b if flag(xx == c) build-depends: xx-c if flag(xx == d) build-d

Re: Opening up Cabal development

> On 14 Jul 2016, at 09:54, Edward Z. Yang wrote: > > Excerpts from Herbert Valerio Riedel's message of 2016-07-13 23:40:06 -0700: >> I.e. write up a specification/proposal outlining motivation (i.e. what >> problem does this solve), specify what the changes are exactly (syntax & >> semantics),

Re: I reorged labels on Cabal's GitHub

Great, it looks awesome. Issue template is great idea as well. (for ones who aren’t familiar: https://github.com/blog/2111-issue-and-pull-request-templates ) (I’m +1 for having GitHub stuff under .github/ directory) The issue templa

Re: I reorged labels on Cabal's GitHub

> On 12 Jul 2016, at 18:42, Edward Z. Yang wrote: > > Excerpts from Oleg Grenrus's message of 2016-07-12 04:03:43 -0700: >> Looks good indeed! >> >> I have few questions: >> - what is purpose of `paging:*` labels, to help people see issues they are >> interested in? How it’s different from ass

Re: I reorged labels on Cabal's GitHub

Looks good indeed! I have few questions: - what is purpose of `paging:*` labels, to help people see issues they are interested in? How it’s different from assignees (which can be multiple)? - why “bug” has “ezyang planning to delete this tag”. I’d prefer to have “type: bug” and other “type:*” la

Re: Anybody using the "top-down" solver?

I doubt this list has good coverage. You probably should try haskell-cafe? Another way to put this question: Is anybody is still using GHC 6.x? Cheers, Oleg > On 09 Nov 2015, at 06:29, Bardur Arantsson wrote: > > Hi all, > > Just to get input from as many people as possible: I was ponderin