-
Notifications
You must be signed in to change notification settings - Fork 63
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
Allow specifying a stack.yaml for stack configurations #230
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi!
Looks nice already!
I think it would be better if you could declare the stackYaml
per cradle, not only per component. e.g. turn this
cradle:
stack:
- path: "./src/full"
component: Agda:lib
stackYaml: stack-8.8.3.yaml
- path: "./src/main"
component: Agda:exe:agda
stackYaml: stack-8.8.3.yaml
into, e.g.
cradle:
stack:
- path: "./src/full"
component: Agda:lib
- path: "./src/main"
component: Agda:exe:agda
stackYaml: stack-8.8.3.yaml
or something else to avoid all this repetition.
Also, are these paths expected to be relative to the cradle root directory?
What would happen in the face of nested multi-cradles, such as:
cradle:
multi:
- path: "appA"
config:
cradle:
stack:
- path: ./src
component: appA:lib
stackYaml: stack-8.8.3.yaml
- path: "appB"
config:
cradle:
stack:
- path: ./src
component: appB:lib
stackYaml: stack-8.8.3.yaml
I guess in this case, the stackYaml
needs to be relative to the cradleRootDir, otherwise we can not express the case that appA
and appB
have the same parent stack.yaml
file.
Unfortunately cradle:
stack:
config: stack-8.8.3.yaml
components:
- path: "./src/full"
target: Agda:lib
- path: "./src/main"
target: Agda:exe:agda But it would be out of scope of this pr... |
Paths are supposed to be relative to the
|
I added a test case ( cradle:
multi:
- path: "appA"
config:
cradle:
stack:
- path: appA/src
component: appA:lib
stackYaml: stack-8.8.3.yaml
- path: "appB"
config:
cradle:
stack:
- path: appB/src
component: appB:lib
stackYaml: stack-8.8.3.yaml |
I'm a bit lost as to why the 8.10.1 test cases are failing, after all. I use ghc 8.10.1 locally, too. Apart from this issue the test appear just fine. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything looks pretty nice so far!
I dont have much time this week, but I plan to review it next weekend!
EDIT: should I forget to review till next week, feel free to ping me.
Ping @fendor |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the long wait!
Awesome work, I just have a few questions.
The config parser is way more permissive than it used to. While that is ok in principle, there are some oddities.
E.g. this configuration:
cradle:
cabal:
component: "exe:cabal"
components:
- path: "./src"
component: "lib:hie-bios"
- path: "./"
component: "lib:hie-bios"
components:
- path: "./src"
component: "exe:hie-bios"
- path: "./"
component: "exe:hie-bios"
is allowed and produces this config, which seems weird and wrong in my opinion:
Config
{ cradle =
CradleConfig
{ cradleDependencies = []
, cradleType =
CabalMulti
{ defaultCabal = Cabal { component = Just "exe:cabal" }
, subCabalComponents =
[ ( "./src" , Cabal { component = Just "exe:hie-bios" } )
, ( "./" , Cabal { component = Just "exe:hie-bios" } )
]
}
}
}
I don't think this should be allowed, even if it semi well-defined.
Other than that, LGTM. Just the parser is a bit too permissive in my opinion. But if you would like to tackle that in a follow up PR, I don't mind merging it.
| Stack { component :: Maybe String } | ||
| StackMulti [ (FilePath, String) ] | ||
= Cabal { cabalType :: !CabalType } | ||
| CabalMulti { defaultCabal :: !CabalType, subCabalComponents :: [ (FilePath, CabalType) ] } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also allows the config file:
cradle:
cabal:
components:
- path: "./src"
component: "lib:hie-bios"
- path: "./"
component: "lib:hie-bios"
While I dont expect any harm of it (and maybe we want soonish a similar field for cabal) but I just wanted to document it.
= fail "Not a valid Configuration type, following keys are allowed: component" | ||
parseStackOrCabal _ multiConstructor (Array x) = do | ||
let parseOne e | ||
parseSingleOrMultiple single multiple parse = doParse where |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interestingly, this allows this configuration:
cradle:
cabal:
components:
- path: "./src"
component: "lib:hie-bios"
- path: "./"
component: "lib:hie-bios"
components:
- path: "./src"
component: "exe:hie-bios"
- path: "./"
component: "exe:hie-bios"
with this result:
Config
{ cradle =
CradleConfig
{ cradleDependencies = []
, cradleType =
CabalMulti
{ defaultCabal = Cabal { component = Nothing }
, subCabalComponents =
[ ( "./src" , Cabal { component = Just "exe:hie-bios" } )
, ( "./" , Cabal { component = Just "exe:hie-bios" } )
]
}
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good catch, didn't think about multiple components
entries. I'll fix this before the PR is merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking about this a little bit more, isn't a duplicate key (components
) an error according to the yaml spec?
Mapping nodes are somewhat tricky because their keys are unordered and must be unique.
In that case, I suppose this PR is relevant and https://github.com/mpickering/hie-bios/pull/230/files#diff-0478bef4574ee638b0c136cccc31479aR288 should use decodeFileWithWarnings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a test case that's supposed to fail on the config with duplicate components
key.
This makes a lot of sense to have, what is the |
@bubba Maybe I'm missing something but I was basing the consideration on the implemented reality in Additionally, it seems that the main entry point |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Co-authored-by: fendor <[email protected]>
In response to #44 this PR adds an argument to
Stack/StackMulti
configurations for providing an explicitstack.yaml
file to use. This is hard to do with generic additional arguments as mentioned in #44 sincestackCradleDependencies
has to know about it, so I decided to give it special syntax. Example hie.yaml (which I'd use for agda/agda)A few questions remain, of course, hence this is a draft.
Naming for
stackYaml
could simply beyaml
A small semantic change is that multistack/multicabal configurations are now allowed to only have a
path
key, defaulting the rest, not requiring acomponent
. Imo, this is better behaviour anyway.Test cases
Documentation