Replace bundled jquery/jquery-flot with js-jquery/js-flot #38

Closed
iustin opened this Issue May 2, 2015 · 10 comments

Comments

Projects
None yet
3 participants
@iustin
Contributor

iustin commented May 2, 2015

Context: in order to simplify downstream packaging (w.r.t licensing, duplicate copies, etc.), @ndmitchell wrote two Haskell libraries that should unify the shipping of JQuery for Haskell projects. Incidentally, ekg uses and ships the same JS libraries (jquery and jquery-flot) that are packaged, so it would be a good idea to remove the shipped files and instead depend on those two libraries.

Let me know if you agree with this plan, and I'll try to send a pull request.

@ndmitchell

This comment has been minimized.

Show comment
Hide comment
@ndmitchell

ndmitchell May 2, 2015

I had such a pull request on my todo list, so thanks for taking it over @iustin!

I had such a pull request on my todo list, so thanks for taking it over @iustin!

@ndmitchell

This comment has been minimized.

Show comment
Hide comment
@ndmitchell

ndmitchell May 2, 2015

To get an idea of what such a pull request might look like, here's the one I did for criterion: bos/criterion#72

To get an idea of what such a pull request might look like, here's the one I did for criterion: bos/criterion#72

@iustin

This comment has been minimized.

Show comment
Hide comment
@iustin

iustin May 2, 2015

Contributor

@ndmitchell - indeed, the delta seems small as expected, thanks for the info (and for the jquery libraries)!

Contributor

iustin commented May 2, 2015

@ndmitchell - indeed, the delta seems small as expected, thanks for the info (and for the jquery libraries)!

@tibbe

This comment has been minimized.

Show comment
Hide comment
@tibbe

tibbe May 4, 2015

Owner

This is a nice initiative, but I have some concerns: I'm not actually using the version of js-flot in #39, but an earlier version, which leads me to my second concern: I now must make sure that I stay up-to-date with this library or else we might see package version conflicts when two Hackage packages use two different versions of js-flot.

Owner

tibbe commented May 4, 2015

This is a nice initiative, but I have some concerns: I'm not actually using the version of js-flot in #39, but an earlier version, which leads me to my second concern: I now must make sure that I stay up-to-date with this library or else we might see package version conflicts when two Hackage packages use two different versions of js-flot.

@iustin

This comment has been minimized.

Show comment
Hide comment
@iustin

iustin May 4, 2015

Contributor

That's a valid concern, but note that the js-* Haskell libraries versioning is set to match the javascript version (up to a certain number of digits). So one can encode the javascript version dependency into cabal - I was wondering whether to do that in ekg.cabal or not, but I'm not familiar with javascript versions as it is.

Regarding js-flot in particular, I've noted that in the commit message - the change from 0.7 to 0.8 seems to be just the split of time from base flot; the other seem to be non-impacting (to me); please check https://github.com/flot/flot/blob/master/NEWS.md#flot-080.

Contributor

iustin commented May 4, 2015

That's a valid concern, but note that the js-* Haskell libraries versioning is set to match the javascript version (up to a certain number of digits). So one can encode the javascript version dependency into cabal - I was wondering whether to do that in ekg.cabal or not, but I'm not familiar with javascript versions as it is.

Regarding js-flot in particular, I've noted that in the commit message - the change from 0.7 to 0.8 seems to be just the split of time from base flot; the other seem to be non-impacting (to me); please check https://github.com/flot/flot/blob/master/NEWS.md#flot-080.

@ndmitchell

This comment has been minimized.

Show comment
Hide comment
@ndmitchell

ndmitchell May 4, 2015

I think staying up to date with js-flot is probably a good plan - newer versions will work with the current crop of browsers, working around the latest flaws and taking advantage of the latest features. Staying still means your code may well start to break on newer versions. You can nail down the version if you want though.

The fact that two hackage packages can't use different versions of a dependent library which they don't expose any interface of is pretty sad - but yes - it's certainly a drawback of standardising - but one that's true of any dependency. To try and minimise that, the js libraries have no dependencies other than base, but it's still more dependencies and thus more chances of conflict.

I think staying up to date with js-flot is probably a good plan - newer versions will work with the current crop of browsers, working around the latest flaws and taking advantage of the latest features. Staying still means your code may well start to break on newer versions. You can nail down the version if you want though.

The fact that two hackage packages can't use different versions of a dependent library which they don't expose any interface of is pretty sad - but yes - it's certainly a drawback of standardising - but one that's true of any dependency. To try and minimise that, the js libraries have no dependencies other than base, but it's still more dependencies and thus more chances of conflict.

@tibbe

This comment has been minimized.

Show comment
Hide comment
@tibbe

tibbe May 5, 2015

Owner

I haven't (unfortunately) been able to stay up-to-date with js-flot far and I don't think that will change. :(

Owner

tibbe commented May 5, 2015

I haven't (unfortunately) been able to stay up-to-date with js-flot far and I don't think that will change. :(

@iustin

This comment has been minimized.

Show comment
Hide comment
@iustin

iustin May 5, 2015

Contributor

@tibbe - what do you think then of upgrading now to 0.8 and making a hardcoded dependency on js-flot == 0.8? Or do you think that even in the future, the cost of moving to new js-flot versions will be higher than what someone who uses ekg but can't compile it due to js-flot dependencies is willing to pay via a pull request?

Also, what about moving just to js-jquery? (Suboptimal for Debian, but it's one step forward)

Contributor

iustin commented May 5, 2015

@tibbe - what do you think then of upgrading now to 0.8 and making a hardcoded dependency on js-flot == 0.8? Or do you think that even in the future, the cost of moving to new js-flot versions will be higher than what someone who uses ekg but can't compile it due to js-flot dependencies is willing to pay via a pull request?

Also, what about moving just to js-jquery? (Suboptimal for Debian, but it's one step forward)

@ndmitchell

This comment has been minimized.

Show comment
Hide comment
@ndmitchell

ndmitchell May 6, 2015

Upgrading jquery/flot was a real pain for Shake until I switched (find the files, check the licenses, do it all in a Debian compliant way). Now it's easy enough you might be able to get a drive-by pull request.

Upgrading jquery/flot was a real pain for Shake until I switched (find the files, check the licenses, do it all in a Debian compliant way). Now it's easy enough you might be able to get a drive-by pull request.

@tibbe

This comment has been minimized.

Show comment
Hide comment
@tibbe

tibbe May 8, 2015

Owner

I've decide to not do this, for now. I might revisit this in the future.

Owner

tibbe commented May 8, 2015

I've decide to not do this, for now. I might revisit this in the future.

@tibbe tibbe closed this May 8, 2015

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