3 ms·

Thanks for elaborating a bit. It honestly does sound like a novel idea but untenable unless the whole nodeJS community changes. And they're moving in the opposi

Thanks for elaborating a bit. It honestly does sound like a novel idea but untenable unless the whole nodeJS community changes. And they're moving in the opposite direction with new tools like yarn. It also doesn't account for different team members running different OSs. npm/yarn are platform independent, rpm is not. That's probably why the javascript community didn't use rpm. Not because its "unsexy" as you speculate... like I said, npm & rpm solve totally different problems. One is made for interactively installing linux binary packages on a specific distro, and requires config management like Ansible to orchestrate in an automated fashion. Whereas npm/yarn is made for platform independence & copying javascript files into a directory, not system binaries, and has a manifest which makes automated builds easier. I agree that rpm does a better job at installing linux packages than npm does at installing javascript packages, but hey, I didn't write the tools. Nor do I want to write my own package manager... As a JS dev I want something that works out of the box, not something I have to write custom scripts for. Maybe someone will make it usable for the masses & npm will be a thing of the past someday, I look forward to that day. I think one of the biggest differences that affects reliability is npm uses github repos, which each author can change, or delete without moderation. AFAIK redhat moderates their repository & does extra leg work to make sure things work together. Its probably also easier to keep things stable when you only target 1 platform.

dozzie 9y ago
> It honestly does sound like a novel idea but untenable unless the whole nodeJS community changes. The thing is, it's not novel by any stretch. Sysadmins use this method for almost twenty years already. About the only novel part (i.e. I didn't read it anywhere but thought up myself) is the binary package that contains all the modules required by web application, and even this I don't believe I was the first person to do. And it's not untenable. It's not a method for distributing code to other programmers, it's a deployment method. Everybody can use it on their own method, without looking at Node.JS community. > It also doesn't account for different team members running different OSs. It's a deployment method. Everybody in the team is free to make as big mess with any other tool as they like, as long as the end thing builds properly for production system, and you can easily provide everybody a virtual machine for checking if build process still works. > npm/yarn are platform independent, rpm is not. Not quite. RPM does run on different platforms (OpenPKG proved practicality of this long time ago), and even then, you don't want a build from macOS or from desktop Fedora running on Debian in the production. Binary packages show up in the picture not in the process of writing the code, but in deployment. > like I said, npm & rpm solve totally different problems. One is made for interactively installing linux binary packages on a specific distro, and requires config management like Ansible to orchestrate in an automated fashion. Not quite, for both of the claims. DPKG and RPM started as such, but they are designed to allow to anchor the installation root in an arbitrary directory. And managing configuration? That's not DPKG or RPM thing, and you get exactly the same with any other deployment method (unless you do the brain-dead thing and ship the configuration hardcoded in the deployed artifact). > Whereas npm/yarn is made for platform independence & copying javascript files into a directory, not system binaries, and has a manifest which makes automated builds easier. This doesn't differ even a bit from how DPKG and RPM operate. The only difference is that npm and Yarn are written in JavaScript, while DPKG and RPM are in C/C++. > I think one of the biggest differences that affects reliability is npm uses github repos, which each author can change, or delete without moderation. And this is where building binary packages from source packages comes into the picture. Debian, Ubuntu, Fedora, or CentOS can rebuild their whole repositories even without the original source tarballs available in their official place (it could have changed, it could have expired, project could have been shut down, or for any number of other reasons). Full source is kept in the very same package repository as binary packages, along with build scripts, patches, and all the other things necessary for build. > AFAIK redhat moderates their repository & does extra leg work to make sure things work together. Curation of the upstream OS has nothing to do with using your own RPM or DEB repository for deploying code to your own infrastructure. > Its probably also easier to keep things stable when you only target 1 platform. Oh, but for production you are targeting just one platform. I'm yet to hear about anybody who deploys their own software to servers running more than one OS flavour. Usually production for in-house developed web software is quite homogenic, all runs under Ubuntu or all runs under Debian or all runs under CentOS.

dozzie 9y ago

> It honestly does sound like a novel idea but untenable unless the whole nodeJS community changes. The thing is, it's not novel by any stretch. Sysadmins use this method for almost twenty years already. About the only novel part (i.e. I didn't read it anywhere but thought up myself) is the binary package that contains all the modules required by web application, and even this I don't believe I was the first person to do. And it's not untenable. It's not a method for distributing code to other programmers, it's a deployment method. Everybody can use it on their own method, without looking at Node.JS community. > It also doesn't account for different team members running different OSs. It's a deployment method. Everybody in the team is free to make as big mess with any other tool as they like, as long as the end thing builds properly for production system, and you can easily provide everybody a virtual machine for checking if build process still works. > npm/yarn are platform independent, rpm is not. Not quite. RPM does run on different platforms (OpenPKG proved practicality of this long time ago), and even then, you don't want a build from macOS or from desktop Fedora running on Debian in the production. Binary packages show up in the picture not in the process of writing the code, but in deployment. > like I said, npm & rpm solve totally different problems. One is made for interactively installing linux binary packages on a specific distro, and requires config management like Ansible to orchestrate in an automated fashion. Not quite, for both of the claims. DPKG and RPM started as such, but they are designed to allow to anchor the installation root in an arbitrary directory. And managing configuration? That's not DPKG or RPM thing, and you get exactly the same with any other deployment method (unless you do the brain-dead thing and ship the configuration hardcoded in the deployed artifact). > Whereas npm/yarn is made for platform independence & copying javascript files into a directory, not system binaries, and has a manifest which makes automated builds easier. This doesn't differ even a bit from how DPKG and RPM operate. The only difference is that npm and Yarn are written in JavaScript, while DPKG and RPM are in C/C++. > I think one of the biggest differences that affects reliability is npm uses github repos, which each author can change, or delete without moderation. And this is where building binary packages from source packages comes into the picture. Debian, Ubuntu, Fedora, or CentOS can rebuild their whole repositories even without the original source tarballs available in their official place (it could have changed, it could have expired, project could have been shut down, or for any number of other reasons). Full source is kept in the very same package repository as binary packages, along with build scripts, patches, and all the other things necessary for build. > AFAIK redhat moderates their repository & does extra leg work to make sure things work together. Curation of the upstream OS has nothing to do with using your own RPM or DEB repository for deploying code to your own infrastructure. > Its probably also easier to keep things stable when you only target 1 platform. Oh, but for production you are targeting just one platform. I'm yet to hear about anybody who deploys their own software to servers running more than one OS flavour. Usually production for in-house developed web software is quite homogenic, all runs under Ubuntu or all runs under Debian or all runs under CentOS.