-
Notifications
You must be signed in to change notification settings - Fork 141
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
[etlas] Dhall package format #946
Comments
Good points! I will comment one by one:
Agree, they can be automatically added and set in scope for all config files. Moreover, if user want to shadow them with its own versions it will be able to do it cause
👍
It would generate:
And for libs or executables you could do:
So no need for record keys (although you could use them). I am afraid that it is not a great improvement in conciseness though. We even could put in scope "sets" of dependencies to match the more common use cases.
The possibilities would be endless 😄
I am afraid that for now dhall has no sense of text comparation. It is so by design, to enforce use of lists Records and Union types, more verbose but safer.
I think it would be realizable
You always can use |
A caveat about add implicit definitions is you cant use dhall executables to proccess the file. |
Hi, i've changed the defaults in
To make dependencies more ergonomic i am thinking in create dhall files with the packages and their bounds and import them in
Attached how looks the |
Attaching the equivalent cabal file: |
I think we could change |
The improvement with dependencies is very nice.
The names Everything else looks good, now we have to decide how to handle built-ins. @jneira What's your plan on that front? |
Yeah, i was thinking in make shorter that ones too, but you cant pass arbitrary records to a function, so you have to choose the set of fields to be filled... we can choose only the required ones or something, i'll take a look. I am currently adding the ivy notation to |
Ivy notation already added so the dependencies would be let dep = prelude.Dependency.singleInterval
.....
build-depends =
[ deps.base
, deps.bytestring
, deps.containers
, deps.contravariant
, deps.cryptonite
, deps.dhall
, deps.eta-java-interop
, deps.megaparsec
, deps.memory
, deps.scientific
, deps.serialise
, deps.text
, deps.transformers
]
# [ dep "dotgen" "[0.4.2,0.5)"
, dep "lens-family-core" "[1.0.0,1.3)"
, dep "prettyprinter" "[1.2.0.1,1.3)"
] I've moved |
Sounds good. Will you be submitting a PR to |
@rahulmutt submitted typelead/etlas-index#22! Otoh i've made some progress in simplify the project and components: i've chosen the basic fields for build etlas project as a subset of actual cabal
It focuses int the fields more used by etlas projects but if you want to use another one you will have to switch to complete With this, the
|
@jneira This looks beautiful now, thanks! Can you commit these changes into etlas? And also somehow lock-in |
@rahulmutt by default it would use the last version of |
@rahulmutt also, do you think that will be interesting to let users use directly
|
@jneira Perhaps we can add some |
oh, yeah, using |
I've updated dhall support for 1.26.1 of dhall-to-etlas and etlas: typelead/etlas#108 |
This issue is to discuss the refinements to the
etlas.dhall
format to make it more concise and readable than it already is as we get closer to releasing Etlas v1.6.0.0 which will makeetlas.dhall
the default format.Cc: @jneira - Maintainer of the Dhall integration in Etlas
As a starting point to this discussion, I'll suggest some things that I think might make it cleaner using this sample etlas.dhall as a reference for discussion as it is a non-trivial example of real-world usage.
Observe
It makes sense to bind each version of Etlas to a certain version of
dhall-to-etlas
and have these two lines automatically added in by Etlas with perhaps flags to customize these since the Etlas code expects the Dhall data structures to be in a certain way when translating to the internalGenericPackageDescription
type.Haskell2010
should be the default language so there should be no release to bind it. Once we release an Eta standard, we can make that the default.pkg
andpkgVer
should both be included inside of some standard library for Etlas package format that is auto-let binded similar to (1).Observe
Note that we had to type in
base
twice! And I have to do this for every dependency I have. Does dhall have a way to traverse the the keys of a record generically so that we can make it a mapping from package name to version bounds? Also, perhaps we can use the Ivy notation for managing version bounds - it's compact and avoids the awkward&&
and comparison operations. (i.e."[4.5, 5)"
would mean>= 4.5 && <= 5
.updateRepo
should probably also be a built-in.Observe
It is very rare that one decides to disable an extension. Perhaps we should abstract out those
True
's and make disabling happen through a function? Also, I'm not completely familiar with Dhall, but is there any language feature that lets you abstract out the long qualified names - like somehow shortentypes.Extension.DataKinds
toDataKinds
in the context ofextensions
?The text was updated successfully, but these errors were encountered: