4 ms·

Speaking from the linux distro perspective, this is not true. You can develop an application in python that utilizes distro-supplied python libraries. If you

Speaking from the linux distro perspective, this is not true. You can develop an application in python that utilizes distro-supplied python libraries. If you package your library in .deb or .rpm, it's trivial to utilize the dependencies from the distro. Otherwise, you can install from pypi via pip, and especially into a virtualenv. You can declare each dependency's specific version if you so choose. Modern distros support python2.7 and python 3.x. If you're on some other operating system, yeah, using python sucks for you. While it's fair to say python is not statically compiled, it's no different than managing dependencies in other dynamically linked software. Unlike python, go applications have to be cross compiled. For the most part, native python code will run anywhere the interpreter runs. In the world of containerized applications, vendoring dependencies is a moot point anyway. We're all shipping around big tarballs with everything baked in anyway, so go doesn't offer any advantages in that space other than smaller binary size. Not to say that go doesn't have some advantages over python, but I think the dependency management problem is vastly overstated, at least when it comes to python.

Spivak 8y ago
> You can develop an application in python that utilizes distro-supplied python libraries. And unless you're aggressively tracking your distro's package releases you'd better hope that the new libdep doesn't introduce any breaking bugs. Also your app is no longer for Linux it's for Ubuntu 18.04 updated roughly on 2018-08-03. The same goes for the actual python. Distributions apply lots of downstream patches and backport fixes so your python 2.7 is really redhat-python2.7-13 so you might want to test against that -- or you can bundle your own and be done with it. Unless you have the wall clock time to actually define and test supported distributions you probably want to pretend the system python doesn't exist. > pypi via pip, and especially into a virtualenv I would never subject my users to this workflow. What you're describing are source distribution channels which are (ab)used to distribute applications. I have no idea if some dependency's native extension will even compile on their system. Do they even have build tools? Why would they?
- dozzie 8y ago
  > And unless you're aggressively tracking your distro's package releases you'd better hope that the new libdep doesn't introduce any breaking bugs. Or use a distribution that does not break shit left and right, like Debian or Red Hat (CentOS). > Unless you have the wall clock time to actually define and test supported distributions you probably want to pretend the system python doesn't exist. If you write software that will be run by others (which usually means open source, probably libraries), yes. If you write software that will only be run by you (pretty much all dynamic websites a.k.a. webapps land in this category), you don't want to have three different distributions in half a dozen different versions anyway, so you can pin yourself to the target environment just as well.
  - eadmund 8y ago
    > Or use a distribution that does not break shit left and right, like Debian or Red Hat (CentOS). Sadly, there are a community of devs who want to rely on libflakey 0.0.1-beta, released an hour ago, and think that waiting for APIs to stabilise & distros to securely package things is unprofessional (!).
    - linuxftw 8y ago
      Using libflakey (lol!) is not necessarily a bad thing; The proper course would be to pull out what you need, make sure the interface you care about is sane and works well; you can revisit the upstream in the future. Raw npm-style clone-from-master seems to be prolific, though.
  - linuxftw 8y ago
    > If you write software that will be run by others (which usually means open source, probably libraries), yes. If you write software that will only be run by you (pretty much all dynamic websites a.k.a. webapps land in this category), you don't want to have three different distributions in half a dozen different versions anyway, so you can pin yourself to the target environment just as well. Yeah, my primary software development mode is 1) gather opensource software, 2) build web app or platform-specific app. > Or use a distribution that does not break shit left and right, like Debian or Red Hat (CentOS). It's crazy that this even has to be said in this day and age. I suppose distro specific patches to maintain a secure and stable api has gone away in favor of some vendored static dependencies that may or may not ever be upgraded, and rebasing your dependencies introduces the same set of problems. I foresee dynamically linked go with platform specific binary packaging becoming the future. Recompiling the same bits of software ad infinitum is probably going to get old.

Spivak 8y ago

> You can develop an application in python that utilizes distro-supplied python libraries. And unless you're aggressively tracking your distro's package releases you'd better hope that the new libdep doesn't introduce any breaking bugs. Also your app is no longer for Linux it's for Ubuntu 18.04 updated roughly on 2018-08-03. The same goes for the actual python. Distributions apply lots of downstream patches and backport fixes so your python 2.7 is really redhat-python2.7-13 so you might want to test against that -- or you can bundle your own and be done with it. Unless you have the wall clock time to actually define and test supported distributions you probably want to pretend the system python doesn't exist. > pypi via pip, and especially into a virtualenv I would never subject my users to this workflow. What you're describing are source distribution channels which are (ab)used to distribute applications. I have no idea if some dependency's native extension will even compile on their system. Do they even have build tools? Why would they?

dozzie 8y ago
> And unless you're aggressively tracking your distro's package releases you'd better hope that the new libdep doesn't introduce any breaking bugs. Or use a distribution that does not break shit left and right, like Debian or Red Hat (CentOS). > Unless you have the wall clock time to actually define and test supported distributions you probably want to pretend the system python doesn't exist. If you write software that will be run by others (which usually means open source, probably libraries), yes. If you write software that will only be run by you (pretty much all dynamic websites a.k.a. webapps land in this category), you don't want to have three different distributions in half a dozen different versions anyway, so you can pin yourself to the target environment just as well.
- eadmund 8y ago
  > Or use a distribution that does not break shit left and right, like Debian or Red Hat (CentOS). Sadly, there are a community of devs who want to rely on libflakey 0.0.1-beta, released an hour ago, and think that waiting for APIs to stabilise & distros to securely package things is unprofessional (!).
  - linuxftw 8y ago
    Using libflakey (lol!) is not necessarily a bad thing; The proper course would be to pull out what you need, make sure the interface you care about is sane and works well; you can revisit the upstream in the future. Raw npm-style clone-from-master seems to be prolific, though.
- linuxftw 8y ago
  > If you write software that will be run by others (which usually means open source, probably libraries), yes. If you write software that will only be run by you (pretty much all dynamic websites a.k.a. webapps land in this category), you don't want to have three different distributions in half a dozen different versions anyway, so you can pin yourself to the target environment just as well. Yeah, my primary software development mode is 1) gather opensource software, 2) build web app or platform-specific app. > Or use a distribution that does not break shit left and right, like Debian or Red Hat (CentOS). It's crazy that this even has to be said in this day and age. I suppose distro specific patches to maintain a secure and stable api has gone away in favor of some vendored static dependencies that may or may not ever be upgraded, and rebasing your dependencies introduces the same set of problems. I foresee dynamically linked go with platform specific binary packaging becoming the future. Recompiling the same bits of software ad infinitum is probably going to get old.