4 ms·

> this is solved with virtualenv Except when you run into edge cases, which happens all the time.

by hasenj 9y ago

gruez 9y ago
elaborate?
- jeffshek 9y ago
  Most of the time pip installs work fine, but once a while after some type of OS upgrade (namely, my experience has been MacOS), you run into odd compiler types of issues. So it's why a lot of teams will use either Vagrant / Docker to setup local developer environments.
  - 0xCMP 9y ago
    Can confirm that once upgrading macOS required using Docker to be productive, because some C-dep we had stopped working. We have developers using macOS 10.10 to avoid any issues (although they're likely gone by now, it's not worth the effort to figure it out anymore).
- jon_richards 9y ago
  I've occasionally had things spontaneously break. Most recently the cryptography package just stopped installing on deployment. Had to add a pip upgrade on deploy, which somehow prevented the AMI I was using from installing some of its requirements. Had to add those packages to my project requirements. Also some of the data analysis packages don't work with virtualenv.
  - dozzie 9y ago
    > Most recently the cryptography package just stopped installing on deployment. Had to add a pip upgrade on deploy, [...] Erm... Why the heck are you running pip when deploying software? O_o It should be a build step, not a deployment step.
    - jon_richards 9y ago
      For a number of reasons, I haven't bothered to do a complex build/deploy process. I write in python, I freeze the requirements into requirements.txt, and I type "eb deploy". Anything else is overkill for me.
      - dozzie 9y ago
        And then you have different lists of installed packages in your development environment and in the production and even between two different production servers (which can silently and/or subtly break your software), and you need to manually install all the C/C++ libraries and compilers and non-Python tools and whatnot, and the upgrade process takes a lot of time and can break on problems with PyPI and/or packages that went missing, and you can't even sensibly downgrade your software to an earlier version. Yes, avoiding learning how to properly package and deploy your software is totally worth this cost.
        hasenj 9y ago
        Python does not really have a "build" step. _That_ is the problem. I think Heroku also played a role in prolifirating the idea that you can just push your code (from a git repo) to a server, and the server will take care of deploying it. Which usually means the server will install all the dependencies from pip during the process.
    - hasenj 9y ago
      Most deploy scripts I've seen tend to do this. Which is insane in my opinion, but the python toolset encourage this kind of approach by making it the default easy thing to do. That's one of the things I prefer about Go: the compiler can cross-compile, so I can compile the entire codebase on my osx machine and produce a single statically linked linux binary that I can just copy over scp to the server. Deployment becomes infinitely simpler.
      - dozzie 9y ago
        > Most deploy scripts I've seen tend to do this. Which is insane in my opinion [...] Also, most programmers don't know a thing about administering servers. Ubiquity doesn't mean that it's a proper way, as you clearly see yourself. > [...] the python toolset encourage this kind of approach by making it the default easy thing to do. It's not quite the fault of Python tooling in particular. It's really the easiest way in general. Similarly, the easiest way to deploy a unix daemon is to run it as root user, because the daemon will have automatically access to all files and directories it needs (data storage, temporary files, sockets, pidfiles, log files). Anything else that is easier to manage requires to put a non-zero effort. > That's one of the things I prefer about Go: [static linking] Static linking has its own share of administrative problems. It's not all nice and dandy.
- hasenj 9y ago
  When you build a piece of software on many layers of abstractions, something will eventually break and leak all the way up in a nasty way that is difficult to debug or fix. I don't have specific examples in mind but I've had a lot of frustrations with virtual-env.
Rotareti 9y ago
Are you using the newer venv package from the stdlib or the old virtualenv package from pypi? I have never encountered a single issue with the former.

> this is solved with virtualenv Except when you run into edge cases, which happens all the time.

by hasenj 9y ago

> this is solved with virtualenv Except when you run into edge cases, which happens all the time.

gruez 9y ago

elaborate?

jeffshek 9y ago
Most of the time pip installs work fine, but once a while after some type of OS upgrade (namely, my experience has been MacOS), you run into odd compiler types of issues. So it's why a lot of teams will use either Vagrant / Docker to setup local developer environments.
- 0xCMP 9y ago
  Can confirm that once upgrading macOS required using Docker to be productive, because some C-dep we had stopped working. We have developers using macOS 10.10 to avoid any issues (although they're likely gone by now, it's not worth the effort to figure it out anymore).
jon_richards 9y ago
I've occasionally had things spontaneously break. Most recently the cryptography package just stopped installing on deployment. Had to add a pip upgrade on deploy, which somehow prevented the AMI I was using from installing some of its requirements. Had to add those packages to my project requirements. Also some of the data analysis packages don't work with virtualenv.
- dozzie 9y ago
  > Most recently the cryptography package just stopped installing on deployment. Had to add a pip upgrade on deploy, [...] Erm... Why the heck are you running pip when deploying software? O_o It should be a build step, not a deployment step.
  - jon_richards 9y ago
    For a number of reasons, I haven't bothered to do a complex build/deploy process. I write in python, I freeze the requirements into requirements.txt, and I type "eb deploy". Anything else is overkill for me.
    - dozzie 9y ago
      And then you have different lists of installed packages in your development environment and in the production and even between two different production servers (which can silently and/or subtly break your software), and you need to manually install all the C/C++ libraries and compilers and non-Python tools and whatnot, and the upgrade process takes a lot of time and can break on problems with PyPI and/or packages that went missing, and you can't even sensibly downgrade your software to an earlier version. Yes, avoiding learning how to properly package and deploy your software is totally worth this cost.
      - hasenj 9y ago
        Python does not really have a "build" step. _That_ is the problem. I think Heroku also played a role in prolifirating the idea that you can just push your code (from a git repo) to a server, and the server will take care of deploying it. Which usually means the server will install all the dependencies from pip during the process.
  - hasenj 9y ago
    Most deploy scripts I've seen tend to do this. Which is insane in my opinion, but the python toolset encourage this kind of approach by making it the default easy thing to do. That's one of the things I prefer about Go: the compiler can cross-compile, so I can compile the entire codebase on my osx machine and produce a single statically linked linux binary that I can just copy over scp to the server. Deployment becomes infinitely simpler.
    - dozzie 9y ago
      > Most deploy scripts I've seen tend to do this. Which is insane in my opinion [...] Also, most programmers don't know a thing about administering servers. Ubiquity doesn't mean that it's a proper way, as you clearly see yourself. > [...] the python toolset encourage this kind of approach by making it the default easy thing to do. It's not quite the fault of Python tooling in particular. It's really the easiest way in general. Similarly, the easiest way to deploy a unix daemon is to run it as root user, because the daemon will have automatically access to all files and directories it needs (data storage, temporary files, sockets, pidfiles, log files). Anything else that is easier to manage requires to put a non-zero effort. > That's one of the things I prefer about Go: [static linking] Static linking has its own share of administrative problems. It's not all nice and dandy.
hasenj 9y ago
When you build a piece of software on many layers of abstractions, something will eventually break and leak all the way up in a nasty way that is difficult to debug or fix. I don't have specific examples in mind but I've had a lot of frustrations with virtual-env.

Rotareti 9y ago

Are you using the newer venv package from the stdlib or the old virtualenv package from pypi? I have never encountered a single issue with the former.