4 ms·

The worst thing about them is the fact that they are installed into global site-packages that you shouldn’t use for any serious coding. And yes, they are mostl

• viraptor 15y ago
  > "into global site-packages that you shouldn’t use for any serious coding" Any specific reason for that? I find it quite good and have quite large deployments using .debs only with packages in global location. (tens of packages produced locally - either updated or unavailable dependencies and the service itself) Any direct dependency is handled by package pinning and no update goes into production untested, so the whole "new sqlalchemy suddenly appears" issue does not exist. As long as people don't break API versioning in silly ways, what's the problem with this? The only version-related issue I remember was when someone thought it would be nice to install something through pip, instead of via package. (went to /usr/local)
  • hynek 15y ago
    What is the benefit of using global packages? If you pin them, what do you gain? virtualenv give you complete control over the runtime environment of every single application. Stuff like what you wrote can’t really happen. And BTW, there’s more stuff that can happen than breaking APIs: new bugs that happen only on your system or even better: your code worked only _because_ of a bug. :)
    • viraptor 15y ago
      For me the benefit is a much easier security audit/update. Unless you have dependencies packaged by yourself, the only thing you need to monitor is what comes into security-updates of your repository. If there's anything new, do a test deployment, do what you do to verify it's correct and change the pin in production. Honestly: how many people installing software through virtualenv are registered to security mailing lists for each of their packages (and their dependencies down to things like simplejson)?
      • hynek 15y ago
        But if you _pin_ your packages, how are you updating? You have to monitor it anyway. High profile projects like simplejson, Django or Pyramid and their deps won’t be missed and the really obscure ones will never make it into the repositories anyway.
        • viraptor 15y ago
          Of course. I'm just saying that in case you're pinning only the default upstream versions from your distro so that they don't change, it's easier to automatically report on which packages have a new version in {distro}-security repository. Then retest and change the pin. The same can be achieved by subscribing to CVEs... but you have to remember to filter the ones you use. Of course that's not a huge difference, so if someone prefers the second way, there's nothing wrong with it ;)
  • j_baker 15y ago
    Having a global python installation where packages are constantly installed, uninstalled, and updated is the path to madness. If something goes wrong, what can you do? You can't wipe out the system python. You can wipe out a virtualenv though.
    • viraptor 15y ago
      What do you mean by goes wrong? Either some package is installed or not. For me, chef manages which ones are. If something is really FUBAR, then wiping is exactly the path I'd take - or more accurately, take that server down for analysis of how exactly it got into that state (so we won't do that again) and bring a clean one up.
      • mbreese 15y ago
        Mainly it's about incompatibilities. What if you have two apps that require different versions of a library? If you've installed it in site-packages, then you have little recourse. By separating them out with virtualenv the two apps will work just fine.
        • viraptor 15y ago
          Fortunately I'm in a one-service-one-server environment, so I may be biased here ;)
          • pbiggar 15y ago
            Well, not really, because what if ubuntu packages rely on version X, and you need version Y.
            • davvid 15y ago
              You roll version Y yourself and install it into an alternate prefix. If the server uses debian that means make a new deb and deploy it using the standard tools. apt-get/yum/etc. are very solid deployment tools.
  • brown9-2 15y ago
    You never have two apps deployed on the same server that need different versions of a dependency?
  • antihero 15y ago
    Your system python applications might have different requirements to your project. Just use virtualenv, it's easier and less error-prone.