[Haskell-community] [Haskell-cafe] technical thoughts on stack

[Harendra Kumar]

While I agree that stack.yaml is a frozen config, we do not necessarily
need a separate config file or a separate format for that. My main point
was a that a new user will have to understand two more languages
(YAML/cabal) in addition to Haskell. We can have the config spread in
multiple files, but they should look like an extension of the same thing
rather than disparate things.

The stack snapshot config can be seen as a higher level concept of the
pvp-bounds in the cabal file. While pvp-bounds specifies a whole range, the
snapshot is a point in that space. It can also be seen as a more general
version of the "tested-with" field in the cabal file. We can instead say -
tested-with these snapshots (or set of versions). Instead of using
stack-7.8.yaml, stack-8.0.yaml manually, the build tool itself can list
which snapshot configs that are available and you can choose which one you
want to build. The config could be tool agnostic.

-harendra

On 15 September 2016 at 11:36, Patrick Pelletier <code at funwithsoftware.org>
wrote:

> On 9/14/16 7:46 PM, Harendra Kumar wrote:
>
>> That's good news. I think the community will benefit from a healthy
>> competition among the tools. It is good to have choices in terms of the
>> front end but I would rather prefer a unified specification of
>> configuration. Currently with a stack workflow one has to deal with two
>> config files i.e. stack.yaml and project.cabal. There is no reason why the
>> stack and cabal configs cannot be unified.
>>
>
> To me, the stack.yaml and project.cabal file serve different purposes.
> The project.cabal specifies how to build a single package.  Even if you
> want to (try to) build that library in a very different build environment,
> everything in the project.cabal is still meaningful: source files,
> dependencies, license, how to run tests and benchmarks, etc.
>
> The stack.yaml is about an entire build environment.  It is about things
> that have to (of necessity) be the same for all the packages that go into
> an executable: compiler version, snapshot, etc.
>
> In other words, a single build environment can build many packages, and a
> single package can be built in many different environments. For example, in
> my directory structure for developing normalization-insensitive, I have
> three stack.yaml files:
>
> stack-7.8.yaml
> stack-7.10.yaml
> stack-8.0.yaml
>
> and I have three cabal files:
>
> unicode-transforms/unicode-transforms.cabal
> normalization-insensitive/normalization-insensitive.cabal
> photos/photos.cabal
>
> Each stack.yaml builds all three cabal projects.  And each cabal project
> can be built by any of the three stack.yaml files.  So, I see them as
> expressing very different concepts.
>
> Another point that I want to make is that I have found the cabal config
>> files hard to deal with. There are a number of annoying problems with it
>> and it lacks in reuse. That is the reason for tools like hpack (
>> https://github.com/sol/hpack) to be built to overcome those problems. I
>> think the problems that hpack solves should be natively solved by cabal.
>>
>
> Yes, it would be nice if cabal-the-library could learn from hpack and
> solve some of the problems like redundancy.  I just wouldn't want to see
> fragmentation of the Haskell ecosystem.  (In other words, I want to be able
> to easily use any Haskell library as a dependency, even if the tools I am
> using are different than the tools the package author used.)
>
> I guess these problems are long pending and cabal did not evolve fast
>> enough. That could be one of the reasons for wrappers on top of cabal or
>> competing tools like stack getting created.
>>
>
> Well, hpack is addressing issues with the file format used by
> cabal-the-library, while stack is addressing issues with
> cabal-install-the-program.
>
> Are there any thoughts going towards a better config specification? While
>> we are at it it maybe good to have an extensible config which can provide
>> optional tool specific extensions.
>>
>
> Yes, that would be very nice.
>
> --Patrick
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-community/attachments/20160915/2410e7f7/attachment.html>