Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's Package JQuery: A JavaScript Packaging Dystopian Novella

dustycloud.org

Post reply on HN
Print view View original

11–20 of 32 posts

Re: Let's Package JQuery: A JavaScript Packaging Dystopian Novella

#11

Post by paulfurtado »

raziel2p wrote: post #7

I fail to see the problem. Just create a .tar.gz with all the dependencies installed and assets compiled, which you can distribute to users that don't care about or don't want to mess around with the build tools. If I want to build a native application (like git, which I often do) from source, it's not like the situation is much better. I have to install the compiler obviously, and I have to manually install the depe…

You usually don't have to manually install a compiler and all the dependencies. If you want to build a package from source which has already been packaged by the distribution, it's usually quite easy to do so. For example, in Arch Linux you can run

yaourt -Sb git

and it will get the PKGBUILD file for the package and allow you to edit it before building so you can build a newer version or alter build flags. When building a package this way, it will also fetch all of the packages it depends on in order to build and run. You generally don't have to think about dependencies at all.

In Ubuntu/Debian and Fedora/CentOS it is several more commands, although there are probably scripts that do it in a single command. It's still a lot easier than manually hunting dependencies and figuring out how exactly to build a package.

Re: Let's Package JQuery: A JavaScript Packaging Dystopian Novella

#13

Post by icebraining »

seanp2k2 wrote: post #10
jamielinux wrote: post #8

T.C. and I worked on getting jQuery packaged for Fedora [1]. It's quite painful trying to package npm modules in a way that's suitable for distributions like Red Hat/Fedora/Debian. The dependency tree just goes on and on and on, and there are versioning issues all over the shop. And if you want to run test suites in the package build process then you'd better package mocha, tap, tape, nodeunit, should, vows, expresso…

Honest question, not trolling: why would I want to install a front-end JS lib using a system package manager? What is the use-case for doing this?

Self-hosted web apps (the linked post mentions MediaGoblin). The idea is that a user can run 'apt-get/yum install mediagoblin' on his home computer and have a personal media server.

Re: Let's Package JQuery: A JavaScript Packaging Dystopian Novella

#14

Post by quanticle »

Animats wrote: post #9

From the article: "Our deployment and build setups have gotten so complicated that I doubt anyone really has a decent understanding of what is going on, really." There's now a school of thought in the Rust world that it's easier to just build a static executable and ship that.

I think Go also follows this philosophy.

Re: Let's Package JQuery: A JavaScript Packaging Dystopian Novella

#15

Post by daleharvey » 

  > It doesn't help that, for a long time, the 
  > status quo in all free software web applications 
  > (and indeed all web applications) was to check 
  > javascript and similar served-to-client web 
  > assets straight into your repository.
That really does help, this would have been a short blog post if they were to follow the status quo.

Operating systems trying to deal with managing applications dependencies has been a huge source of fustration for me. You cant have jquery randomly upgraded for your application without having tested it, that is always going to cause problems no matter how religious you are with semver.

Anyone who has developed erlang on ubuntu can attest to how ridiculous the situation can get (debian split erlang up into seperate packages).

I very much lean towards having my dependencies bundled. I have misgivings with npm but it does a lot of things right in that regard.

Re: Let's Package JQuery: A JavaScript Packaging Dystopian Novella

#16

Post by icebraining »

paulfurtado wrote: post #11
raziel2p wrote: post #7

I fail to see the problem. Just create a .tar.gz with all the dependencies installed and assets compiled, which you can distribute to users that don't care about or don't want to mess around with the build tools. If I want to build a native application (like git, which I often do) from source, it's not like the situation is much better. I have to install the compiler obviously, and I have to manually install the depe…

You usually don't have to manually install a compiler and all the dependencies. If you want to build a package from source which has already been packaged by the distribution, it's usually quite easy to do so. For example, in Arch Linux you can run yaourt -Sb git and it will get the PKGBUILD file for the package and allow you to edit it before building so you can build a newer version or alter build flags. When build…

In Ubuntu/Debian and Fedora/CentOS it is several more commands

In Debian & derivatives it's just "apt-get build-dep git && apt-get source --build git".

Re: Let's Package JQuery: A JavaScript Packaging Dystopian Novella

#17

Post by davexunit »

Animats wrote: post #9

From the article: "Our deployment and build setups have gotten so complicated that I doubt anyone really has a decent understanding of what is going on, really." There's now a school of thought in the Rust world that it's easier to just build a static executable and ship that.

>There's now a school of thought in the Rust world that it's easier to just build a static executable and ship that.

If that's where we're headed, I'm extremely sad. Static linking everything is a lazy non-solution, IMO. Rampant duplication, increased resource usage, etc. Not good.

Re: Let's Package JQuery: A JavaScript Packaging Dystopian Novella

#18

Post by davexunit »

seanp2k2 wrote: post #10
jamielinux wrote: post #8

T.C. and I worked on getting jQuery packaged for Fedora [1]. It's quite painful trying to package npm modules in a way that's suitable for distributions like Red Hat/Fedora/Debian. The dependency tree just goes on and on and on, and there are versioning issues all over the shop. And if you want to run test suites in the package build process then you'd better package mocha, tap, tape, nodeunit, should, vows, expresso…

Honest question, not trolling: why would I want to install a front-end JS lib using a system package manager? What is the use-case for doing this?

Deduplication, reproducibility, using only a single package manager instead of a handful, ec.

Re: Let's Package JQuery: A JavaScript Packaging Dystopian Novella

#19

Post by davexunit »

nailer wrote: post #12

To always use the same versions of every dependency you'll want to shrink wrap. And yes, of course dependencies have dependencies. Software depends on other software. All packaging systems have a tree of dependencies.

>To always use the same versions of every dependency you'll want to shrink wrap.

Does "shrink wrap" mean "bundle"? If so, I strongly disagree. It's possible to explicitly use the exact same versions of dependencies without resorting to bundling all the source/binaries. Guix and Nix are particularly well suited for this.

>And yes, of course dependencies have dependencies.

But you have to admit that the depth of this dependency tree is insane.

Re: Let's Package JQuery: A JavaScript Packaging Dystopian Novella

#20

Post by davexunit »

madeofpalk wrote: post #3
cloudsloth wrote: post #2

"265 unique packages, all to build jquery!" Oh my goodness.

To be fair, Node/Javascript prefers to have many small packages that do just one thing (hopefully well).

But the packaging burden is the same, regardless of the size of the source code. There's still 265 unique dependencies for a distro to package to build jQuery from source in its entirety. That's rough.
Post reply on HN