search

gwatts / jquery.sparkline

A plugin for the jQuery javascript library to generate small sparkline charts directly in the browser
http://omnipotent.net/jquery.sparkline/
1.24k stars 278 forks source link

Distribution Script (jquery.sparkline.js) #109

Closed brunobelarmino closed 10 years ago

brunobelarmino commented 10 years ago

Can you available the distribution script (jquery.sparkline.js) on github? I use bower as dependency manager and he seeks scripts from github, which does not have the script in question. Thanks

RuslanZavacky commented 10 years ago

+1

rafanoronha commented 10 years ago

:+1:

jonasabreu commented 10 years ago

+1

willgm commented 10 years ago

+1

brunowego commented 10 years ago

+1

cthrax commented 10 years ago

+1 but in the interim, https://github.com/smysnk/jquery.sparkline exists.

filipegiusti commented 10 years ago

Guys, this won't happen, the repo author said he is against it. The tools need to improve not the libraries needs to comply with tools that can't run a build process.

cthrax commented 10 years ago

Right, because RPM, .deb, .exe, .egg, .dll, etc, etc are all wrong in enforcing some sort of structure to a package. They all really should have adapted to every bit of source they are packaging.

filipegiusti commented 10 years ago

@cthrax the author is not against having bower.json or any other package meta info, he is against checking in the repo distribution packages because the dependency tool isn't capable of running a basic build or accepting deploy of a distribution package.

cthrax commented 10 years ago

I understand the problem just fine, even worked around it. The problem is the library does not provide any release artifacts and expects other tools to take care of that problem because a build script is provided. The maintainer is perfectly within their rights to take this stance, but it seems pretty darn silly to me. And I don't have to be happy about it.

gwatts commented 10 years ago

The release artifacts are linked from the web site. No-one needs to build anything, unless they want to use the bleeding-edge, in which case you're expected to have the expertise to build it and not complain because the master branch is an unfinished release.

This git repo is for collaborative code development, not for release distribution.

Any fork of this repo can do whatever it likes, of course.

If the bower.json can reference the latest release on the web site, then that would be fine with me (ie. a pointer to http://omnipotent.net/jquery.sparkline/latest/jquery.sparkline.js), but I'm not checking in a compiled build into the source repo anytime soon to work around (imo) a design error with Bower.

cthrax commented 10 years ago

@gwatts as I said, you're prerogative, and as I pointed out earlier in the comment chain there is a fork that does accommodate bower, but standing on a high horse, due to a shortcoming (I'd not disagree with design flaw, but bower is still worlds better than having to download dependencies manually) of one of the more common and widely used dependency managers does not fix the problem (design flaw) nor increase the usefulness of a, what I deem, extremely well done library that is used by a large number of people. I'll continue using the fork that meets my needs, but I hope you will reconsider your stance in the future and provide a solution that is a little more accommodating.

Despite my unhappiness with this distribution issue, I'm extremely happy and thankful for the library and do appreciate all the work that's been put into it.

gwatts commented 10 years ago

I appreciate the problem with distribution management, but perhaps if everyone didn't capitulate to the design error, the error would be addressed and we'd all be a bit happier with the solution ;-)

Very pleased to hear that you're finding the library useful though.