Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Automatic generation of hpack from .cabal files? #63

Closed
mgsloan opened this issue Jan 13, 2016 · 6 comments
Closed

Automatic generation of hpack from .cabal files? #63

mgsloan opened this issue Jan 13, 2016 · 6 comments

Comments

@mgsloan
Copy link
Contributor

mgsloan commented Jan 13, 2016

Hpack looks really nice, great work! I think a good step towards adoption would be to support automatic conversion of cabal files to hpack format. This could be done in a new package, hpack-convert, or something, to avoid a dependency on Cabal in the main hpack library (maybe that dependency would be ok, though?).
@soenkehahn
Copy link
Collaborator

Yes, this is definitely something we thought about before. I would prefer this to be in the same project, mainly because I want the hpack executable to be able to perform the conversion.

(edit: typo)

@sol
Copy link
Owner

sol commented Jan 16, 2016

Yes, this is a frequently requested feature and would be an awesome addition to hpack. In general I would prefer a separate package.

@soenkehahn Would you imagine that calling hpack in a situation where (a) there is no package.yaml and (b) there is a cabal file, hpack would generate a package.yaml? In that case we would only need one hpack command, that does not require any arguments.

@mgsloan
Copy link
Contributor Author

mgsloan commented Jan 18, 2016

Hmm, switching behaviors based on context like that seems unpredictable, I think I'd prefer a special command or flag.

I don't see this as really being that difficult. The main bits that could use some fanciness is the error messages for cases that hpack can't handle, and extracting out the common duplication among sections.

@mgsloan mgsloan mentioned this issue Jan 18, 2016
Closed
@soenkehahn
Copy link
Collaborator

@sol: I agree with @mgsloan: I would prefer that hpack has to be explicitly asked (through a flag) to create a package.yaml. I remember calling hpack by mistake on projects that don't have a package.yaml. I imagine it would be a bit inconvenient if hpack would just create one in that case.

@mgsloan mgsloan mentioned this issue Jan 21, 2016
Closed
@yamadapc
Copy link

I started working on this. Need to clean-up the yaml generation bit a lot and I think I broke something, but from hpack.cabal it's generating:

https://gist.github.com/49b34220077bdd9e16ef6d0126d1d66a

yamadapc added a commit to yamadapc/hpack-convert that referenced this issue Aug 2, 2016
@yamadapc
Add conversion from cabal files
cafbf80 
Adds modules `Hpack.Convert` and `Hpack.Convert.Run` for reading a
`GenericPackageDescription` onto a `Package` and running the user-facing
conversion routine.

The user-facing option is exposed through:
```
$ hpack --convert [cabal-file|project-dir]
```

- - -

Also adds tests testing we can read cabal files generated from some of
the README examples and hpack's into package.yamls that look like the
original ones.

Everything should be supported, including converting conditionals.

I really need feedback on how to make `Hpack.Config` `Package` related
`ToJSON` instances cleaner. That's the ugly bit of the code.

There some cases where we run into problems in conversion. For example,
the Cabal library does not expose in its data-structures if `buildable`
was specified or not. To keep the output clean, I initially striped it
from sections if it was true, but then empty conditional blocks could be
generated. Right now it'll only output `buildable` if it's not
redundant based on context. It'll also remove any empty conditional
branches.

This closes sol#63.
@yamadapc yamadapc mentioned this issue Aug 2, 2016
Closed
@mgsloan
Copy link
Contributor Author

mgsloan commented Aug 9, 2016

Good work @yamadapc !!

@mgsloan mgsloan closed this as completed Aug 9, 2016
yamadapc added a commit to yamadapc/hpack-convert that referenced this issue Aug 21, 2016
@yamadapc
Add conversion from cabal files
f702582 
Adds modules `Hpack.Convert` and `Hpack.Convert.Run` for reading a
`GenericPackageDescription` onto a `Package` and running the user-facing
conversion routine.

The user-facing option is exposed through:
```
$ hpack --convert [cabal-file|project-dir]
```

- - -

Also adds tests testing we can read cabal files generated from some of
the README examples and hpack's into package.yamls that look like the
original ones.

Everything should be supported, including converting conditionals.

I really need feedback on how to make `Hpack.Config` `Package` related
`ToJSON` instances cleaner. That's the ugly bit of the code.

There some cases where we run into problems in conversion. For example,
the Cabal library does not expose in its data-structures if `buildable`
was specified or not. To keep the output clean, I initially striped it
from sections if it was true, but then empty conditional blocks could be
generated. Right now it'll only output `buildable` if it's not
redundant based on context. It'll also remove any empty conditional
branches.

This closes sol#63.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add conversion from cabal files yamadapc/hpack-convert
4 participants
@mgsloan @soenkehahn @sol @yamadapc