No, and neither is a Go or Rust binary, next question.
> Is it even portable across different linux distributions?
Nothing preventing me from taking an extra 10 minutes to modify the spec to support SUSE, Fedora support usually comes for free if you support el7.
You like Debian derivatives? Let me toss a debian/ directory in there, that'll only take a couple minutes too.
Added benefit, I'm not just throwing files at a server like some hacky Windows developer doing an xcopy deploy to IIS. I can check what version of my application is deployed, and update it along with the rest of the system if I so desire (setting up a yum or apt repository isn't hard).
> Across different servers running the same distribution but perhaps with different libraries installed?
Different libraries? Do you mean different VERSIONS of libraries? Native libraries have figured this shit out for ages with soname's. Python too, different versions of an egg can be installed side by side, you need to pin a specific version just use pkg_resources.require() in your main script.
> Will another python developer understand how the build process for it is set up and be able to add new dependencies?
I had a Jr. Developer with no experience with Linux or Python pick up building the package and making basic edits to the .spec file 10 minutes. RPM/DEB packaging isn't magic, you describe your package with metadata, write some shell commands to build/install your package in a buildroot, and then list the files from said buildroot to include in the package. You could make your first package from scratch in under an hour if you read the Fedora or Debian wiki guides on packaging.
> Nothing preventing me from taking an extra 10 minutes
Indeed, but 10 minutes here, 10 minutes there, it all adds up.
> Different libraries? Do you mean different VERSIONS of libraries?
No, I mean some native libraries not installed. Does your package declare what packages it depends on? How do you handle different distributions using different package names for the same libraries.
> RPM/DEB packaging isn't magic, you describe your package with metadata, write some shell commands to build/install your package in a buildroot, and then list the files from said buildroot to include in the package. You could make your first package from scratch in under an hour if you read the Fedora or Debian wiki guides on packaging.
Sure, none of it's hard. But if there's no clear standard everyone ends up doing it slightly differently, and then every project you pick up you have to understand how they've set things up.
> Sure, I'm comparing with the JVM per the article.
Fair enough, though I still use RPM's to deploy Java (Spring Boot even!) applications.
> Indeed, but 10 minutes here, 10 minutes there, it all adds up.
In the grand scheme of software development updating the .spec file or debian control file is peanuts.
> No, I mean some native libraries not installed. Does your package declare what packages it depends on? How do you handle different distributions using different package names for the same libraries.
In the case of RPM based distributions, some conditional macro's in the .spec file that swap out Requires/BuildRequires statements based on the distribution the package is being built for. I never bother with SUSE personally, but there are differences between EL7 and Fedora that I have to keep track of.
> But if there's no clear standard everyone ends up doing it slightly differently, and then every project you pick up you have to understand how they've set things up.
.spec files are more standard than most build tooling. The only thing that complicates them is projects without an adequate build system in the first place, everything else is minor style differences based on who wrote the spec.
Everything has been done before, unless you are using some extremely new or extremely niche language or build tool chances are your spec file will be easy to figure out, since any and all complexity is explicitly linked to how easy it is to build and install your software in the first place.
No, and neither is a Go or Rust binary, next question.
> Is it even portable across different linux distributions?
Nothing preventing me from taking an extra 10 minutes to modify the spec to support SUSE, Fedora support usually comes for free if you support el7.
You like Debian derivatives? Let me toss a debian/ directory in there, that'll only take a couple minutes too.
Added benefit, I'm not just throwing files at a server like some hacky Windows developer doing an xcopy deploy to IIS. I can check what version of my application is deployed, and update it along with the rest of the system if I so desire (setting up a yum or apt repository isn't hard).
> Across different servers running the same distribution but perhaps with different libraries installed?
Different libraries? Do you mean different VERSIONS of libraries? Native libraries have figured this shit out for ages with soname's. Python too, different versions of an egg can be installed side by side, you need to pin a specific version just use pkg_resources.require() in your main script.
> Will another python developer understand how the build process for it is set up and be able to add new dependencies?
I had a Jr. Developer with no experience with Linux or Python pick up building the package and making basic edits to the .spec file 10 minutes. RPM/DEB packaging isn't magic, you describe your package with metadata, write some shell commands to build/install your package in a buildroot, and then list the files from said buildroot to include in the package. You could make your first package from scratch in under an hour if you read the Fedora or Debian wiki guides on packaging.