# Convenience in the Haskell ecosystem

**URL:** <https://discourse.haskell.org/t/convenience-in-the-haskell-ecosystem/7731>\
**Category:** Uncategorized\
**Created:** [September 30, 2023, 10:18am UTC](https://discourse.haskell.org/t/convenience-in-the-haskell-ecosystem/7731 "2023-09-30T10:18:40Z")\
**Posts on this page:** 1\
**Showing post:** 50

<div class="post-metadata">

**Author:** ![hasufell](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hasufell/32/1250_2.png) [@hasufell](https://discourse.haskell.org/u/hasufell)\
**Post date:** [October 1, 2023, 4:06pm UTC](https://discourse.haskell.org/t/convenience-in-the-haskell-ecosystem/7731/50 "2023-10-01T16:06:44Z")

</div>

> [@maxigit](#):
>
> Also to guaranatee that the cabal file matches version of ghc and HLS maybe that should be a job for ghcup (rather than cabal). Ghcup generates you a cabal file for the version you selected.

GHCup is an installer, not a cabal file templating mechanism.

This is exactly why we need unix philosophy: tool boundaries shouldn’t be violated, just because an existing tool is popular.

A unix compatible solution to this is already proposed:

> [@An external command system for cabal: what would you do with it?](http://discourse.haskell.org/t/an-external-command-system-for-cabal-what-would-you-do-with-it/7114):
>
> Hi everyone! Cabal is receiving a contribution that implements an external command system like the one implemented by git and cargo. The idea is that when you call cabal \<external\>, cabal will look for cabal-\<external\> in your PATH, and set up environment variables like cabal exec. The idea for us cabal developers is to be able to experiment with new sub-options before integrating them into the cabal-install code base. But we are also interested in what you would like to do with such a featur…

---

_[View the full topic](https://discourse.haskell.org/t/convenience-in-the-haskell-ecosystem/7731)._