-
Notifications
You must be signed in to change notification settings - Fork 691
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
Improve cabal init
defaults
#8465
Comments
For (1), including random packages doesn’t sound useful to me. On the other hand, it’s conceivable that we could have a command-line option for packages to include. A bit unclear: what bounds to use (no bounds is a bad style). Accessing index to determine the latest version of a package during |
For the rest, it’s not clear to me how far it should go (if anywhere). Do you have references for prior art in mind? Stack, npm, whatever. It’d be interesting to see what others do. |
We're more shooting for "not annoying". Most new users of cabal will be confused if they can't use common imports such as Including these packages in the standard project allows both beginners and experienced users to get started on real projects with fewer frictions (most real projects use at least text and containers). That sounds very useful to me. Bounds shouldn't matter for these core packages since they are bundled with GHC. |
The idea is to add boot packages only, and probably only for app components. |
Boot packages are a bunch of random packages that GHC happen to depend upon. I fail to see why they would "improve cabal init defaults". |
A common complaint I've heard is that many common packages are not included in cabal init projects. You can see similar opinions in the inspiration for this issue: https://discourse.haskell.org/t/bringing-data-text-into-base-what-is-the-next-step/5016/40 |
Oh, that DIscourse thread… One thing that I think could be improved inside |
Discussion here seems to have stalled with no consensus. I'd suggest closing this and get back when someone comes up with a proposal that would collect more support. |
Have you considered a model where one could init based on a template that modifies some or all of the Without a kind of plug-in model, a solution seems unmanageable directly from the Cabal repo. Unless cabal is changed the best solution I see is something like Vanessa McHale's project-init. It is a good solution but it replaces |
Templates would be great. Stack has them. But there's always the other side of the coin. Tailoring defaults to your liking looks like a sufficiently orthogonal task that a separate tool could be employed rather than making already huge Yet, if someone would volunteer to implement a light-weight (in terms of amount of code) templating support for |
Many users, including myself, get frustrated when starting a new project. The
cabal init
experience is very pleasant, but the defaults for packages and the generated code could be more practical:cabal init
should include various important packages in the default project (such astext
,containers
,bytestring
)Main.hs
should use some of these packages, so that there are as few "unused package" errors as possibleIs (1) possible? If so, we can come up with some more specific ideas for (2,3,4)
The text was updated successfully, but these errors were encountered: