4 ms·

Do you think websites are somehow different than all the rest of the software that they cannot be put into an RPM nor have all their dependencies bundled in a S

by dozzie 9y ago

Do you think websites are somehow different than all the rest of the software that they cannot be put into an RPM nor have all their dependencies bundled in a SRPM?

joshribakoff 9y ago
Can you please try to communicate in some other way besides asking rhetorical questions, it comes off as rude & elitist. AFAIK most package managers are essentially a .tar with a checksum. Is there some specific toolset or methodology you follow? Eg. how does each project declare which RPMs? How are these RPMs getting created, by hand and one per package? Or one per project, via some kind of tool? I've literally never heard of anyone using rpms for nodeJS dependencies, and I am intrigued. Let's take an example project with 500 sub-folders under node_modules, are you suggesting I bundle the whole project into an rpm including its dependencies? Because I already have server backups & such, which accomplishes the same thing. Before I spent time making an RPM to backup the project, I could just take container backups or something. My actual issue is when you have only minified code, or compiled executable -- and your boss wants you to add new features, but you do not have the sources, only a package.json that references projects that have been deleted. Or worse, no package.json -- not much can be done at this point, the onus was on the original author. Or are you suggesting each dependency gets wrapped into an rpm? Because that sounds time consuming & doesn't seem like it provides any benefit [it'd be just swapping npm for rpm, it sounds like?]. Plus in my parent comment, the example I used, I inherited a project where 10% of the node_modules were simply missing, the project's author built the code, then deleted his node_modules & left the company. I had to derive what the dependencies were by weeding through minified code. Not sure how RPMs help. I'm also not sure how using RPMs helps when you have developers who may be on different distros or mac, now they have to run docker or vagrant to get the frontend deps? ew. But perhaps I'm not understanding what you're suggesting to do with RPMs, you're not communicating very clearly or nicely IMO. Perhaps linking to an example repo employing your technique or an article that explains it in more detail would be a better way to get your point across. AFAIK, RPM & NPM were made to solve totally different problems. Trying to use NPM to manage linux packages or using RPM to manage javascript packages honestly sounds like a nightmare, going against the grain. RPM was made for linux packages, not frontend web development. I'm trying to keep an open mind but you're not explaining yourself.
- dozzie 9y ago
  > AFAIK most package managers are essentially a .tar with a checksum. Yes, basically. By the same way of thinking npm is essentially a variant of wget and shell scripts interpreter for running build rules. It's the details of the implementation and what use techniques are most obvious and convenient that make the tool. > Eg. how does each project declare which RPMs? How are these RPMs getting created, by hand and one per package? For daemons, command line tools, and libraries -- usually one package per repository (sometimes several packages built from a single build rules set, if it makes sense to install part of the project as a standalone thing). Websites, since it's a custom to put a shitload of mostly trivial dependencies that form a fractal, get two packages: the actual code and all dependencies bundled together. Note that all of the packages are not built from source code (and `npm install' or `pip install') directly, but they go through a source package (e.g. SRPM), which is especially important for dependencies. This way you always have a way to rebuild the dependencies in exactly the same versions (e.g. after patching one of them), you have an obvious place to store the dependencies (i.e. along with binary packages; package repositories support serving both) without growing your source repository unnecessarily, and you have an obvious place to apply patches to external dependencies. The only downside is that you'll need to write a downloader script, because language-specific module managers (pip, npm, gem) usually assume their user is too stupid to run as two commands two logically separate steps of fetching and building the packages. > I've literally never heard of anyone using rpms for nodeJS dependencies, and I am intrigued. Well, yes, that's because Node.JS crowd doesn't have the habit of learning what other IT fields were using successfully for decades. > Or are you suggesting each dependency gets wrapped into an rpm? Because that sounds time consuming & doesn't seem like it provides any benefit [it'd be just swapping npm for rpm, it sounds like?]. If the repository was handled the same way as the rest of the code, then yes, there's little benefit. If it was handled the way as the rest of the binary packages are in the distribution, you get for each binary package a source package and uniform build process, so you can rebuild each package every time you need to, and there is good tooling for automating building the packages. > AFAIK, RPM & NPM were made to solve totally different problems. One was created to make installing and deploying code easy, while the other was created to make installing and deploying code easy. Yes, totally different problems. > Trying to use NPM to manage linux packages or using RPM to manage javascript packages honestly sounds like a nightmare, going against the grain. Actually only the former of these is going against the grain. The latter, on the other hand, requires learning tooling that hasn't substantially changed in over a decade and comes from different field, so it's unsexy and uninteresting for most of the programmers. > RPM was made for linux packages, not frontend web development. And how exactly differs deploying some code to a directory and running some daemons between software that comes from a distribution and software that you have written yourself for running a website?

by dozzie 9y ago

Do you think websites are somehow different than all the rest of the software that they cannot be put into an RPM nor have all their dependencies bundled in a SRPM?

joshribakoff 9y ago

Can you please try to communicate in some other way besides asking rhetorical questions, it comes off as rude & elitist. AFAIK most package managers are essentially a .tar with a checksum. Is there some specific toolset or methodology you follow? Eg. how does each project declare which RPMs? How are these RPMs getting created, by hand and one per package? Or one per project, via some kind of tool? I've literally never heard of anyone using rpms for nodeJS dependencies, and I am intrigued. Let's take an example project with 500 sub-folders under node_modules, are you suggesting I bundle the whole project into an rpm including its dependencies? Because I already have server backups & such, which accomplishes the same thing. Before I spent time making an RPM to backup the project, I could just take container backups or something. My actual issue is when you have only minified code, or compiled executable -- and your boss wants you to add new features, but you do not have the sources, only a package.json that references projects that have been deleted. Or worse, no package.json -- not much can be done at this point, the onus was on the original author. Or are you suggesting each dependency gets wrapped into an rpm? Because that sounds time consuming & doesn't seem like it provides any benefit [it'd be just swapping npm for rpm, it sounds like?]. Plus in my parent comment, the example I used, I inherited a project where 10% of the node_modules were simply missing, the project's author built the code, then deleted his node_modules & left the company. I had to derive what the dependencies were by weeding through minified code. Not sure how RPMs help. I'm also not sure how using RPMs helps when you have developers who may be on different distros or mac, now they have to run docker or vagrant to get the frontend deps? ew. But perhaps I'm not understanding what you're suggesting to do with RPMs, you're not communicating very clearly or nicely IMO. Perhaps linking to an example repo employing your technique or an article that explains it in more detail would be a better way to get your point across. AFAIK, RPM & NPM were made to solve totally different problems. Trying to use NPM to manage linux packages or using RPM to manage javascript packages honestly sounds like a nightmare, going against the grain. RPM was made for linux packages, not frontend web development. I'm trying to keep an open mind but you're not explaining yourself.

dozzie 9y ago
> AFAIK most package managers are essentially a .tar with a checksum. Yes, basically. By the same way of thinking npm is essentially a variant of wget and shell scripts interpreter for running build rules. It's the details of the implementation and what use techniques are most obvious and convenient that make the tool. > Eg. how does each project declare which RPMs? How are these RPMs getting created, by hand and one per package? For daemons, command line tools, and libraries -- usually one package per repository (sometimes several packages built from a single build rules set, if it makes sense to install part of the project as a standalone thing). Websites, since it's a custom to put a shitload of mostly trivial dependencies that form a fractal, get two packages: the actual code and all dependencies bundled together. Note that all of the packages are not built from source code (and `npm install' or `pip install') directly, but they go through a source package (e.g. SRPM), which is especially important for dependencies. This way you always have a way to rebuild the dependencies in exactly the same versions (e.g. after patching one of them), you have an obvious place to store the dependencies (i.e. along with binary packages; package repositories support serving both) without growing your source repository unnecessarily, and you have an obvious place to apply patches to external dependencies. The only downside is that you'll need to write a downloader script, because language-specific module managers (pip, npm, gem) usually assume their user is too stupid to run as two commands two logically separate steps of fetching and building the packages. > I've literally never heard of anyone using rpms for nodeJS dependencies, and I am intrigued. Well, yes, that's because Node.JS crowd doesn't have the habit of learning what other IT fields were using successfully for decades. > Or are you suggesting each dependency gets wrapped into an rpm? Because that sounds time consuming & doesn't seem like it provides any benefit [it'd be just swapping npm for rpm, it sounds like?]. If the repository was handled the same way as the rest of the code, then yes, there's little benefit. If it was handled the way as the rest of the binary packages are in the distribution, you get for each binary package a source package and uniform build process, so you can rebuild each package every time you need to, and there is good tooling for automating building the packages. > AFAIK, RPM & NPM were made to solve totally different problems. One was created to make installing and deploying code easy, while the other was created to make installing and deploying code easy. Yes, totally different problems. > Trying to use NPM to manage linux packages or using RPM to manage javascript packages honestly sounds like a nightmare, going against the grain. Actually only the former of these is going against the grain. The latter, on the other hand, requires learning tooling that hasn't substantially changed in over a decade and comes from different field, so it's unsexy and uninteresting for most of the programmers. > RPM was made for linux packages, not frontend web development. And how exactly differs deploying some code to a directory and running some daemons between software that comes from a distribution and software that you have written yourself for running a website?