Re: [RFC] Qualified module renamings

​I added this to the PR! Hopefully it is what you are looking for. From: Bryan Richter Sent: Thursday, February 25, 2021 10:44 PM To: Edward Z Yang Cc: cabal-devel@haskell.org; ekm...@gmail.com Subject: Re: [RFC] Qualified module renamings Thanks for the context

Re: [RFC] Qualified module renamings

motivating use case at https://github.com/haskell/cabal/issues/7290#issuecomment-783540208? although his use case is a little difficult to understand. Edward From: Bryan Richter <mailto:b...@chreekat.net> Sent: Thursday, February 25, 2021 10:06 AM To: Ed

Re: [RFC] Qualified module renamings

se at https://github.com/haskell/cabal/issues/7290#issuecomment-783540208? although his use case is a little difficult to understand. Edward From: Bryan Richter Sent: Thursday, February 25, 2021 10:06 AM To: Edward Z Yang Cc: cabal-devel@haskell.org; ekm.

[RFC] Qualified module renamings

Today, using the 'mixins' field you can rename modules that come from other packages by manually expressing a renaming one-by-one. In some Backpack use cases, you may have a lot of modules that you would like to mechanically rename into some subnamespace; today, you have manually list each

Re: use data-files without installation

: > > On Fri, 3 Mar 2017, Edward Z. Yang wrote: > > > One of the tracking bugs we have for this issue: > > https://github.com/haskell/cabal/issues/4120 > > Note that the data file directory can be overridden > > with environment variables, that might be good enough to

Re: use data-files without installation

One of the tracking bugs we have for this issue: https://github.com/haskell/cabal/issues/4120 Note that the data file directory can be overridden with environment variables, that might be good enough to work around. It would be really nice if inplace data files worked. It is a little tricky to

Fwd: GHC 8.0.2 status

If we want a bugfix version of Cabal in with GHC 8.0.2 this is our last chance. --- Begin forwarded message from Ben Gamari --- From: Ben Gamari To: Gabor Greif , Pali Gabor Janos , Gershom B , Jens Petersen

New milestones for Cabal

I've been trying to do triage on the bugtracker, and I've been pretty unhappy with the old milestone system. So I tried something new: - No more separate Cabal/cabal-install milestones. We're tightly coupled, and if we do uncouple, then we can talk separate, but not while the

Re: Opening up Cabal development

Yep, of course. (I sometimes get the feeling that a less good way people do this is by just not documenting the feature :o) Excerpts from Paolo G. Giarrusso's message of 2016-07-17 04:27:14 -0700: > Edward Z. Yang mit.edu> writes: > > > Excerpts from Herbert Valerio Riedel's mes

Re: Opening up Cabal development

Excerpts from Oleg Grenrus's message of 2016-07-14 02:08:54 -0700: > About convenience libraries I agree even more. We should discussed them more. > There are questions I’d might to ask, but I guess it too late It's not too late. They are not in any real release. They can be removed. > Or maybe

Re: Opening up Cabal development

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), what the consequences are, and so on. > > Then we

Opening up Cabal development

Hey all, Paolo Giarrusso suggested that the Cabal project might look into giving more people commit bits, ala http://felixge.de/2013/03/11/the-pull-request-hack.html I think we do need to give more commit bits. There's a sliding scale of how extreme we can go: 1. We can adopt this

Re: I reorged labels on Cabal's GitHub

mplate could ask for > - Cabal/cabal-install/ghc versions > - ask to run cabal-install with -v2 flag and add that to the issue? > > with quick glance it doesn’t apply to many issues, but when it does, it would > be helpful. > > > - Oleg > > > On 12 Jul 2016, at

Re: I reorged labels on Cabal's GitHub

Thanks for the note. I went ahead and enabled it. Let's see if it's useful! Excerpts from John Alfred Nathanael Chee's message of 2016-07-12 14:18:03 -0700: > On Tue, Jul 12, 2016 at 1:48 PM, Edward Z. Yang <ezy...@mit.edu> wrote: > > > > >- I can put more metad

Re: I reorged labels on Cabal's GitHub

Excerpts from Oleg Grenrus's message of 2016-07-12 12:45:05 -0700: > > > On 12 Jul 2016, at 18:42, Edward Z. Yang <ezy...@mit.edu> wrote: > > > > Excerpts from Oleg Grenrus's message of 2016-07-12 04:03:43 -0700: > >> Looks good indeed! > >> >

Re: I reorged labels on Cabal's GitHub

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 assignees (which can be multiple)? Beyond what Mikhail stated:

I reorged labels on Cabal's GitHub

If you hate it I can change it back but give it a try for now. If the "component" prefix in "component: solver" is too long we could go for something like "C-solver" but I think that is less transparent. I also added some new labels, "paging: ezyang (...)". In the parenthetical should be a quick

Travis PR build notifications on Slack and IRC

Hello all, I'm happy to announce that you can get IRC and Slack notifications for Travis builds on https://github.com/haskell/cabal . This should make it more convenient to submit pull requests as you can get pinged when the build is finished. IRC notifications are only for branches on the main

Re: Running the Cabal tests

I would not worry too much about these; they're a bit touchy due to the use of symlinks. If you could figure out why they are failing that would be helpful though! Edward Excerpts from Erik de Castro Lopo's message of 2016-03-19 21:15:45 -0700: > Erik de Castro Lopo wrote: > > > These test

Re: Running the Cabal tests

Excerpts from Erik de Castro Lopo's message of 2016-03-19 19:24:34 -0700: > Edward Z. Yang wrote: > > > package-tests currently has a dumb hack to figure out these environment > > variables: it tries to read out the local build information associated > > with your build o

Re: Running the Cabal tests

Excerpts from Mikhail Glushenkov's message of 2016-03-19 07:57:42 -0700: > Hi, > > On 19 March 2016 at 08:35, Erik de Castro Lopo wrote: > > Hi all, > > > > I hacked together what I thought was a neat little feature (a 3 line diff) > > and thought I'd add a test. Thats when

PR action-required tag, and a Phabricator instance

Hey all, Two quick reports for Cabal: 1. I've tagged all PRs as either cabal-install/library. This should help triage, since the nature of patches to these different projects can be quite different. 2. I've tagged PRs that are KNOWN to not be mergeable (either due to Travis failure or something

Renaming InstalledPackageId

Hello friends, During discussions with many people about Nix-like Cabal, it has emerged that InstalledPackageId is /really/ bad name. Consider: the commonly accepted definition of an InstalledPackageId in Nix is that it is morally a hash of all the inputs to compilation: the source code, the

Re: Request for feedback on spec/proposal for distributing package collections via hackage

Hello Duncan, In my eyes, this proposal looks like some sort of generalization of Stackage; and one further use case is special purpose collection. My big question: how composable are these collections really? I can't put two collections with conflicting versions together (or can I? Do I

Re: Cabal-1.22 keyed library filepaths

Jens, could file a Cabal bug for the contents of this email? Edward Excerpts from Edward Z. Yang's message of 2015-01-18 22:47:23 -0800: Hey Jens, The motivation for truncating the names and version was to keep symbol name sizes manageable even with the addition of the hash, while giving

Re: Cabal-1.22 keyed library filepaths

Hey Jens, The motivation for truncating the names and version was to keep symbol name sizes manageable even with the addition of the hash, while giving at least some hint when working with the symbols directly. It doesn't seem that this rationale applies for library names, so it's possible we

Re: HEADS UP: Running cabal install with the latest GHC

. The file-style databases are no longer supported. So yes, you will need a new version of cabal-install for GHC HEAD. Cheers, Edward Excerpts from Reid Barton's message of 2014-09-27 09:26:08 -0700: On Fri, Aug 8, 2014 at 8:00 AM, Edward Z. Yang ezy...@mit.edu wrote: Hey all, SPJ pointed out

Status of encapsulations in the modular dependency solver

Hello all, I wanted to know what the status of the encapsulations feature in Cabal is. Presented in HIW'11, the intent was for it to be used to support private dependencies in Cabal. However, while this is was implemented in the modular solver, it looks like it was never wired up with Cabal

HEADS UP: Running cabal install with the latest GHC

Hey all, SPJ pointed out to me today that if you try to run: cabal install --with-ghc=/path/to/inplace/bin/ghc-stage2 with the latest GHC HEAD, this probably will not actually work, because your system installed version of Cabal is probably too old to deal with the new package key stuff in

Re: HEADS UP: Running cabal install with the latest GHC

they easily be cherry-picked onto the 1.20 branch? Are there any risk of breakages? On Fri, Aug 8, 2014 at 2:00 PM, Edward Z. Yang ezy...@mit.edu wrote: Hey all, SPJ pointed out to me today that if you try to run: cabal install --with-ghc=/path/to/inplace/bin/ghc-stage2

Killing or resurrecting version tags for good

Hello all, A while back, I was nattering around the parsing code for Cabal, and I noticed that Cabal still had code for parsing version tags, but was explicitly *not* printing out version tags. I proposed that we should get rid of the parsing code as well, but when I mentioned this on #ghc Mark

Re: Killing or resurrecting version tags for good

Excerpts from Mikhail Glushenkov's message of 2014-07-26 23:44:39 +0100: IIRC, Duncan wants to remove version tags both from Cabal and Data.Version. So perhaps it's time to deprecate them. My question here is orthogonal to the question of deprecation: if we are deprecating them, but not

Removing GHC's dependency on Cabal

Hello all, I know Duncan and SPJ have been keen on removing GHC's dependency on Cabal for some time now. Simon and I were chatting about the subject today, and we wanted to propose an alternative way of doing the remodularization. Here are diagrams of the proposals:

Multi-instance packages status report

Hello all, As you may have noticed, I've been knocking around GHC and Cabal the past few weeks. One of the tasks that has been on my list is essentially reimplementing Philipp Schuster's 2012 GSoC, with a few small but important architectural differences. Here is a status report of what is

InstalledPackageInfo, IPI641, IPI642

Hello all, I am currently adding support for packages to reexport modules (proper) from other packages, but I've run into a nasty bit of BC in Cabal that I don't quite understand; namely, InstalledPackageInfo, IPI641 and IPI642. So, I understand in principle why we might want these data

Re: Cabal and GHC

Excerpts from Simon Peyton-Jones's message of Thu Nov 22 00:32:27 -0800 2012: Now, if Cabal can figure out a plan based on an empty database, it can deliver on that plan even in a non-empty database, without messing up any existing installations. This is an interesting invariant, weaker than

Re: Cabalizing exclusively C projects

Hello Jurian, To do this, you'll want (at least) a recent patchset I wrote for Cabal which is still under review: https://github.com/haskell/cabal/pull/1080 In particular, you'll want the Main-is patch, which lets you tell Cabal that a particular c file contains a main() function. Cheers,

RE: Virtual packages and subpackages

There are two closely related features here (both of which could be useful.) This wasn't helped by me mixing up virtual packages with subpackages (which I think is actually what I wanted.) Here's the relevant quotes: Provides: lets you list virtual package names that this package provides.

Virtual packages

Hello folks, I was thinking a little about how build flags that modify functionality are harmful for dependency resolution (pandoc and xmobar, I'm glaring at you), but authors will still use this feature because it's a lot easier than maintaining a bunch of separate packages for each different

Re: cabal user's guide comment

Hello Jake, Are you asking about the internal implemenation of packages? In that case, it's not too surprising that the User's Manual doesn't say much about: that's a very internal feature, under the abstraction barrier, that the majority of Haskellers should not have to know or worry about. You

Re: Data and Typeable instances for GenericPackageDescription

Excerpts from JP Moresmau's message of Tue Jun 15 14:43:28 -0400 2010: Hello, I was wondering if there are instances for Typeable and Data available somewhere for GenericPackageDescription. Automatic deriving fails, probably, if I read the docs right, because some types in there have more than