-
Notifications
You must be signed in to change notification settings - Fork 697
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add cabal packages
#4493
Comments
Probably better to add |
@23Skidoo that would still require me to understand that there is ghc-pkg, and what it does. I'm coming from a "do not make me think" point of view. Assuming I'm new to haskell. I kind of know there is To me, the leap from And If this line of thought runs counter to cabal's philosophy so be it. I'm likely not acquainted enough with the ways of the cabal yet. |
There's a |
@23Skidoo ...wasn't the recommended way to use
|
@angerman naming nitpick: I'm not sure |
@hvr Yep, right, because it can use a non-default ghc version. |
is this obseleted by new build or handled by #7500 ? |
or by |
I would like to propose that cabal learns about
packages
ornew-packages
, as a wrapper aroundghc-pkg
. The motivation here, is that one needs to use only a single command, and not need to know aboutghc-pkg
.I'd like to see:
where
would be
and
would be
I'm not sure if no flag should be permitted, and which of both scenarios it would be, or if it should list global AND local.
Slightly unrelated, but why do we have
package.db
for global andpackagedb
for local?The text was updated successfully, but these errors were encountered: