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
Edward Kmett described a concrete 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
se 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
Sent: Thursday, February 25, 2021 10:06 AM
To: Edward Z Yang
Cc: cabal-devel@haskell.org;
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 renam
0:
>
> 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 eno
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 do,
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 , "\"Erik
Rantapaa\"" , Erik de Casto Lopo ,
Randy Polen , Karel Gardas ,
Herbert Val
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 proj
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&
I pulled the trigger. If you are mad, talk to me.
https://github.com/haskell/cabal/issues/3567
Edward
Excerpts from Edward Z. Yang's message of 2016-07-13 16:32:39 -0700:
> Hey all,
>
> Paolo Giarrusso suggested that the Cabal project might look into
> giving more people commit bits, ala
> ht
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 n
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 inevitabl
Excerpts from Gershom B's message of 2016-07-13 18:01:50 -0700:
> On July 13, 2016 at 7:32:47 PM, Edward Z. Yang (ezy...@mit.edu) wrote:
>
> The general notion sounds good to me. I’m semi-indifferent between (1)
> and (2) though conservatively lean towards the latter.
>
&g
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 wholesal
ue template 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 Ju
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 wrote:
>
> > > >- I can put more metadat
Excerpts from Oleg Grenrus's message of 2016-07-12 12:45:05 -0700:
>
> > 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!
> >>
> >&g
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:
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
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
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 don'
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 bu
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 I figured out I couldn
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
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
depe
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
union
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 givi
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 cou
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 wrote:
>
> > Hey all,
> >
> > SPJ pointed ou
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
prope
ime,
> etc). Which are the patches in question. Can 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 wrote:
>
> > Hey all,
> >
> > SPJ pointed out to me today that if
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 H
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 removi
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 L
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:
http://web.mit.edu/~ezyang/Pu
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 going
Hello folks,
In the interest in as small changes as possible, I am planning on
updating the version Cabal we're tracking against to Cabal HEAD
(after my build finishes validating, that is!) At a later point,
when someone finally merges https://github.com/haskell/cabal/pull/1991
I'll make a smalle
Hello all,
I am working on module reexports (https://ghc.haskell.org/trac/ghc/ticket/8407)
and this functionality requires concurrent changes to GHC and Cabal.
However, GHC is currently tracking 1.20, but Cabal HEAD has marched on.
My question is, if I am to do this development on HEAD, what is t
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 structure
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 th
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,
E
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.
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 fl
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
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 t
45 matches
Mail list logo