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

[Edward Z. Yang]

On September 16, 2016 9:19:16 AM GMT+09:00, Christopher Allen <cma at bitemyapp.com> wrote:
>The YAML parser backing hpack and Stack supports a subset of yaml, so
>the complexity isn't there.

Is the subset of yaml that Stack supports deacribed anywhere? The yaml package (which Stack depends on) seems to suggest it supports a pretty beefy chunk of YAML, e.g. including includes.

>TOML isn't supported because a well-supported/known-good library
>wasn't to hand, whereas the yaml one did. I don't think people would
>mind changing over, but somebody has to do the work validating that
>the one-still-maintained-of-two-libraries TOML library is suitable.

I'm not suggesting you change over. My feeling is that once a choice like this is made, it is very hard to change post facto. Need to build infrastructure for migrating to new format if you do.

>Keep in mind while discussing all this that Cabal's own solver doesn't
>actually live outside of cabal-install.

Here is the ticket tracking the issue:
https://github.com/haskell/cabal/issues/3781

Basically, everyone agrees it should happen, but there is a bit of work that has to be done, esp. API design, and most of us have other issues we are frying.

> Contributing to the Cabal
>project itself is a gauntlet run, which is partly why many of these
>projects spawned outside of it.

I know that this was true in the past, and it is hard to regain trust and reputation. But I think things are better now. Our turnaround time for new PRs is now much quicker, and if you submit a PR we will give you commit bits. Obviously that doesn't make up for any past failings, but please give us another look!

> Further, Cabal itself can't really
>grow any dependencies because of the bootstrap problem.

I don't think this is inherently unsolvable. Just work. It would be reasonable to remove Cabal from boot packages GHC distributes and require cabal-install/Stack to bootstrap a sufficiently new version of Cabal library. But you would have to do work to make sure that you dont end up building half the universe on a fresh GHC build. GHC devs would not like that.

>Nobody wants to shim / inline all the dependencies that enable the
>devs to work efficiently into Cabal and such a PR would never get
>merged anyway.

Out of curiosity, what are the libraries that are most painful to not have available from the boot libraries?

Edward

>On Thu, Sep 15, 2016 at 6:55 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
>>> How about cabal-install using the YAML format as hpack has proven
>that it
>>> works very well for expressing the existing .cabal files? YAML is
>simple,
>>> flexible and open, used across many tools so the knowledge of format
>is
>>> more widely sharable which has its advantages. Are there reasons to
>keep
>>> using the cabal format other than the legacy reasons and the pain of
>asking
>>> everyone to move to another format?
>>
>> I understand YAML is a very popular format, but it is not all roses.
>> It's an extremely complicated format
>(http://yaml.org/spec/1.2/spec.html).
>> Cabal's lexical format is very simple, because it doesn't really need
>to
>> support much (the rest is deferred to sub-parsers on fields.)  In
>some
>> since, YAML is overkill for Stack, which actually doesn't use very
>many of
>> its features
>(https://docs.haskellstack.org/en/stable/yaml_configuration/)
>>
>> If I were designing a package ecosystem from scratch, I'm not sure
>what
>> format I would pick.  Take Rust Cargo; they didn't use YAML, they
>used
>> TOML (https://github.com/toml-lang/toml) in no small part due to the
>> fact that YAML is complicated.  I'd want the output to be associated
>> with locations so I could give error messages that refer to the input
>> file; no one does that today...
>>
>>> Inputs from original stack authors might also be useful on why they
>chose
>>> YAML over .cabal. I guess it might be similar to the reasons why
>someone
>>> wrote hpack to generate .cabal from YAML. Also they were starting
>fresh and
>>> so did not have to manage a disruptive change. But I fear if they
>will be
>>> willing to go for a closed format against an open format now even if
>some
>>> of the problems of the format are addressed. Maintaining a closed
>format
>>> perennially is also an issue unless it is very well thought out and
>does
>>> not require any changes.
>>
>> I suspect the reason is much more banal: Cabal's parser
>implementation
>> is pretty byzantine and difficult to use. So rather than fight
>something
>> like that, just use something will a nicer API.
>>
>> Edward
>> _______________________________________________
>> Haskell-community mailing list
>> Haskell-community at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.