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

Use more accurate license tag in Cabal file. #512

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
2 participants
@peti
Contributor

peti commented Mar 8, 2017

No description provided.

@simonmichael

Nice!

Are these changes necessary ? The new version seems a little less clear:

-    , .
 +      ./.
@peti

This comment has been minimized.

Show comment
Hide comment
@peti

peti Mar 8, 2017

Contributor

Those changes come from recent versions of hpack. I just ran that tool; I didn't edit the Cabal files myself.

Contributor

peti commented Mar 8, 2017

Those changes come from recent versions of hpack. I just ran that tool; I didn't edit the Cabal files myself.

@simonmichael

This comment has been minimized.

Show comment
Hide comment
@simonmichael

simonmichael Mar 8, 2017

Owner

I see, ./. seems to be a workaround for sol/hpack#119.

Next, are we sure GPL-3 is valid ? I remember looking for it in the past, and it's not mentioned in the Cabal docs -> license -> License type.

Owner

simonmichael commented Mar 8, 2017

I see, ./. seems to be a workaround for sol/hpack#119.

Next, are we sure GPL-3 is valid ? I remember looking for it in the past, and it's not mentioned in the Cabal docs -> license -> License type.

@simonmichael

This comment has been minimized.

Show comment
Hide comment
@simonmichael

simonmichael Mar 8, 2017

Owner

The ./. change happens with hpack 0.16 or greater. My stack binary has hpack 0.14 built in (and building a new stack doesn't seem to change that). This can cause hpack warnings and thrashing between the . and ./. formats. Are you not using stack ?

Owner

simonmichael commented Mar 8, 2017

The ./. change happens with hpack 0.16 or greater. My stack binary has hpack 0.14 built in (and building a new stack doesn't seem to change that). This can cause hpack warnings and thrashing between the . and ./. formats. Are you not using stack ?

@peti

This comment has been minimized.

Show comment
Hide comment
@peti

peti Mar 9, 2017

Contributor

Next, are we sure GPL-3 is valid?

Yes.

I remember looking for it in the past, and it's not mentioned in the Cabal docs -> license -> License type.

Note that the GPL constructor of License has a Version argument. That is where the -3 bit ends up.

Building a new stack doesn't seem to change [the hpack version].

stack can be built with recent versions of hpack. You might be able to force that by passing --constraint=hpack==0.17.* on the command-line to cabal (or whatever it is, exactly, that you use to build stack). It probably doesn't happen by default because your package database contains version 0.14 of the tool already.

Are you not using stack?

No. I used it for a while, but then I went back to plain cabal-install (with Nix behind it to provide pre-built binaries if possible).

Contributor

peti commented Mar 9, 2017

Next, are we sure GPL-3 is valid?

Yes.

I remember looking for it in the past, and it's not mentioned in the Cabal docs -> license -> License type.

Note that the GPL constructor of License has a Version argument. That is where the -3 bit ends up.

Building a new stack doesn't seem to change [the hpack version].

stack can be built with recent versions of hpack. You might be able to force that by passing --constraint=hpack==0.17.* on the command-line to cabal (or whatever it is, exactly, that you use to build stack). It probably doesn't happen by default because your package database contains version 0.14 of the tool already.

Are you not using stack?

No. I used it for a while, but then I went back to plain cabal-install (with Nix behind it to provide pre-built binaries if possible).

@simonmichael

This comment has been minimized.

Show comment
Hide comment
@simonmichael

simonmichael Mar 9, 2017

Owner
Owner

simonmichael commented Mar 9, 2017

@peti

This comment has been minimized.

Show comment
Hide comment
@peti

peti Mar 9, 2017

Contributor

According to http://hackage.haskell.org/package/stack, stack requires hpack >=0.14.0 && <0.18, so I don't see why building it with a recent version should be a problem. We certainly do build stack with a recent hpack in NixOS and it works fine.

Contributor

peti commented Mar 9, 2017

According to http://hackage.haskell.org/package/stack, stack requires hpack >=0.14.0 && <0.18, so I don't see why building it with a recent version should be a problem. We certainly do build stack with a recent hpack in NixOS and it works fine.

@simonmichael

This comment has been minimized.

Show comment
Hide comment
@simonmichael

simonmichael Mar 10, 2017

Owner

For non-cabal users, installing a stack that uses hpack 0.17 is not yet that easy, because of other dependency constraints. (stack install stack gets you hpack 0.14; stack install stack-1.3.2 doesn't work yet; you have to use the stack source dir or some other trick). I'd prefer to separate these issues (updating license tag and updating hpack format).

Owner

simonmichael commented Mar 10, 2017

For non-cabal users, installing a stack that uses hpack 0.17 is not yet that easy, because of other dependency constraints. (stack install stack gets you hpack 0.14; stack install stack-1.3.2 doesn't work yet; you have to use the stack source dir or some other trick). I'd prefer to separate these issues (updating license tag and updating hpack format).

@peti

This comment has been minimized.

Show comment
Hide comment
@peti

peti Mar 10, 2017

Contributor

I'm not sure what real-world action you associate with "separating these issues"? How do we move forward from here?

Contributor

peti commented Mar 10, 2017

I'm not sure what real-world action you associate with "separating these issues"? How do we move forward from here?

@simonmichael

This comment has been minimized.

Show comment
Hide comment
@simonmichael

simonmichael Mar 10, 2017

Owner

I meant, can you (force) push a new commit to this PR which just changes the license field. That makes it easy to accept.

Owner

simonmichael commented Mar 10, 2017

I meant, can you (force) push a new commit to this PR which just changes the license field. That makes it easy to accept.

@simonmichael

This comment has been minimized.

Show comment
Hide comment
@simonmichael

simonmichael Mar 10, 2017

Owner

PS I'm sorry for the tedious push back on what you probably thought was a trivial fix. :) I can do it if you prefer. Also I clarified my earlier comment a bit at #512 (comment)

Owner

simonmichael commented Mar 10, 2017

PS I'm sorry for the tedious push back on what you probably thought was a trivial fix. :) I can do it if you prefer. Also I clarified my earlier comment a bit at #512 (comment)

@simonmichael

This comment has been minimized.

Show comment
Hide comment
@simonmichael

simonmichael Mar 15, 2017

Owner

Merged e2c8a6a. Thanks!

Owner

simonmichael commented Mar 15, 2017

Merged e2c8a6a. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment