3 ms·

The problem with targeting Debian Stable + Backports is that your packages are going to perpetually out of date unless you go to the trouble of packaging up you

The problem with targeting Debian Stable + Backports is that your packages are going to perpetually out of date unless you go to the trouble of packaging up your dependencies as .debs and running your own apt server. Targeting Debian stable is fine if you can get away with using three year old libraries. But for a lot of languages, like Python, 3 year old libraries are at a significant feature disadvantage when compared to their current counterparts.

calpaterson 11y ago
Debian stable includes pip and virtualenv. If you want to manage your python dependencies for yourself that road is definitely open to you.
- icebraining 11y ago
  Mixing pip and debs loses some of the advantages of having a standard system, though. I think you're better off producing deb packages from PyPI in your build server.
  - chei0aiV 11y ago
    There are some tools to help out with that: https://wiki.debian.org/AutomaticPackagingTools https://wiki.debian.org/AutomaticPackagingTools https://summit.debconf.org/debconf15/meeting/257/automatic-packaging/ https://summit.debconf.org/debconf15/meeting/257/automatic-p...
  - justizin 11y ago
    I typically rec installing virtualenv systemwide, if a reasonable version is available by package, and managing per-app dependencies in a requirements.txt that's platform agnostic. The Debian ecosystem is great, but I would never recommend a developer marry an app to it.
    - icebraining 11y ago
      But there's no reason you can't have the cake and eat it too; you can create a virtualenv from a requirements.txt file on your build server, then package it up in a deb package that installs those files in a custom directory (not in the shared Python modules path). That way, you get static artifacts you can deploy (instead of deploying using pip, which requires compiling any non-pure-python package on the server), you get to use apt's dependencies for non-Python packages, like system libraries, and you can easily rollback by simply pushing the previous version of the deb package, which is cleaner than rolling back with pip, in my experience.
annnnd 11y ago
When you say "out of date", you probably mean feature wise, not security and stability wise? For me that is an acceptable tradeoff for most of the packages. Most of the stuff doesn't evolve at such pace that I should have the latest and greatest (I am talking about core libs and similar). And the packages where I miss some new functionality, I can just upgrade them manually. Take Firefox for instance - if you don't like/trust Iceweasel, you can just install FF to /opt/ and trust Mozilla for upgrades. For me this is win-win situation. You have a stable and secure foundation and you put bleeding edge stuff on it when you need it.
- tankenmate 11y ago
  Indeed, for myself I prefer stable releases (Debian, Ubuntu LTS, etc) and use apt pinning so that I can use newer versions of apps that I need to use. Very rarely will I have a problem; in fact the few times there is a problem it is normally solved by apt-get source ; dpkg-buildpackage.
  - stephenr 11y ago
    Do you just use pinning straight out the gate, or do you check backports (or whatever equivalent Ubuntu has) first?
    - tankenmate 11y ago
      It depends, normally in order of preference LTS, LTS backports, then latest release. So then if you want the newer version you can do apt-get install <package>/<release>. I typically use Apt::Default-Release "<release>" in a separate apt.conf.d file.
- XorNot 11y ago
  Just yesterday I had a problem which was some combination of Debian Jessie's incredibly outdated Python CFFI library (0.8.6) and its interaction with OpenSSL which took a script from taking milliseconds to launch to over 1.5 seconds, purely due to that import.

calpaterson 11y ago

Debian stable includes pip and virtualenv. If you want to manage your python dependencies for yourself that road is definitely open to you.

icebraining 11y ago
Mixing pip and debs loses some of the advantages of having a standard system, though. I think you're better off producing deb packages from PyPI in your build server.
- chei0aiV 11y ago
  There are some tools to help out with that: https://wiki.debian.org/AutomaticPackagingTools https://wiki.debian.org/AutomaticPackagingTools https://summit.debconf.org/debconf15/meeting/257/automatic-packaging/ https://summit.debconf.org/debconf15/meeting/257/automatic-p...
- justizin 11y ago
  I typically rec installing virtualenv systemwide, if a reasonable version is available by package, and managing per-app dependencies in a requirements.txt that's platform agnostic. The Debian ecosystem is great, but I would never recommend a developer marry an app to it.
  - icebraining 11y ago
    But there's no reason you can't have the cake and eat it too; you can create a virtualenv from a requirements.txt file on your build server, then package it up in a deb package that installs those files in a custom directory (not in the shared Python modules path). That way, you get static artifacts you can deploy (instead of deploying using pip, which requires compiling any non-pure-python package on the server), you get to use apt's dependencies for non-Python packages, like system libraries, and you can easily rollback by simply pushing the previous version of the deb package, which is cleaner than rolling back with pip, in my experience.

annnnd 11y ago

When you say "out of date", you probably mean feature wise, not security and stability wise? For me that is an acceptable tradeoff for most of the packages. Most of the stuff doesn't evolve at such pace that I should have the latest and greatest (I am talking about core libs and similar). And the packages where I miss some new functionality, I can just upgrade them manually. Take Firefox for instance - if you don't like/trust Iceweasel, you can just install FF to /opt/ and trust Mozilla for upgrades. For me this is win-win situation. You have a stable and secure foundation and you put bleeding edge stuff on it when you need it.

tankenmate 11y ago
Indeed, for myself I prefer stable releases (Debian, Ubuntu LTS, etc) and use apt pinning so that I can use newer versions of apps that I need to use. Very rarely will I have a problem; in fact the few times there is a problem it is normally solved by apt-get source ; dpkg-buildpackage.
- stephenr 11y ago
  Do you just use pinning straight out the gate, or do you check backports (or whatever equivalent Ubuntu has) first?
  - tankenmate 11y ago
    It depends, normally in order of preference LTS, LTS backports, then latest release. So then if you want the newer version you can do apt-get install <package>/<release>. I typically use Apt::Default-Release "<release>" in a separate apt.conf.d file.
XorNot 11y ago
Just yesterday I had a problem which was some combination of Debian Jessie's incredibly outdated Python CFFI library (0.8.6) and its interaction with OpenSSL which took a script from taking milliseconds to launch to over 1.5 seconds, purely due to that import.