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
_______________________________________________
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
