5 ms·

It is pretty simple: when I spin up an EC2 instance on amazon, and I type "python" in the console, whatever version that is will be the version I use.

by skizm 10y ago

lima 10y ago
Nowadays, I no longer use the distribution Python at all. Debian Stable and pyenv it is. That way, I have a rock solid operating system and my application are completely decoupled. Using distribution packages for application deployments is insane. It makes sense for workstation or systems software where the application you develop is part of the operating system, but for a server application, it makes no sense at all.
- snuxoll 10y ago
  I use distribution packages for all my deployments, period. I have no desire to maintain a separate system for installing an upgrading my own applications versus those provided in repositories already. Time to push out a new release? `tito release koji-el7`, SRPM built and sent to Koji to be built and packaged, every 15 minutes mash runs to update our internal yum repo from Koji - and next time Puppet runs the package is automatically upgraded to the latest version without me having to do anything. No virtualenv's, no tarballs, nothing special beyond an RPM. I won't deploy software any other way (and if something doesn't already have an RPM I will make one for it).
  - kstrauser 10y ago
    Note to self: snuxoll likes pushing boulders up hills by ignoring all the tooling people have invented to make this stuff easy.
    - snuxoll 10y ago
      > ignoring all the tooling people have invented to make this stuff easy. I don't, I just use the standard one that comes with the operating system instead of insisting on re-inventing the wheel because "packaging is hard". I could have just had tito push directly to a yum repository if I so desired, but it's much nicer to use Koji (which I'm already familiar with).
      - kstrauser 10y ago
        > I don't, I just use the standard one that comes with the operating system ...which is "ignoring all the tooling people have invented to make this stuff easy". virtualenv and pip were explicitly designed to work around two damn nigh insurmountable problems: 1) OS vendors move slowly, and 2) Sometimes two projects on the same machine need two different libraries It's trivial to use virtualenv and pip to make Project A and Project B run side by side with different Python versions and completely different dependency manifests. You can come up with your own ad-hoc system to deal with this or you can adapt the best practice of every other Python shop. Make no mistake though: your current way is deliberately choosing the hard road.
        snuxoll 10y ago
        virtualenv is trying to solve a problem that's already solved by setuptools and eggs, and doing a shitty job at it. Back before eggs where a thing, sure, virtualenv had a purpose - but now there's absolutely no need to create a completely independent environment when you can just use pkg_resources.require() or just add the appropriate eggs to sys.path. Virtualenv doesn't make my life any easier, it makes deploying applications harder since I have to write a custom deployment pipeline - whereas I already maintain RPM's for other non-python software we use internally, and I can use the same infrastructure to handle them both. Edit: For most of our applications the latest Fedora Server release is also our target host, so "distributions moving slowly" is rarely an excuse as typically the latest packages are available (and if not we make them ourselves, like we do for selenium).
        takeda 10y ago
        You have mixed up history line. Eggs are older than virtualenv, from the times of easy_install. Now there are wheels that are nicely integrated with pip. Also virtualenv became integrated into python (it's called pyvenv now).
        anamoulous 10y ago
        Another option here is to pin your Python version to whatever Anaconda is. It's very easy to install and use Anaconda in production.
  - takeda 10y ago
    https://ius.io/ https://ius.io/ is your friend. Among many things you have all versions of python available that don't conflict with system packages or themselves. What's awesome is that you can install multiple versions and all of them just work.
- matt_wulfeck 10y ago
  They aren't completely decoupled. Even with a virtenv you still need to install and maintain a lot of library and header packages on the host OS.
  - lima 10y ago
    Well, almost completely. The build dependencies don't change nearly as fast as the application, and are generally backwards compatible.
  - Filligree 10y ago
    For complete decoupling, better use NixOS.
    - lima 10y ago
      Or Docker containers :-)
  - takeda 10y ago
    That's problem which is solved with wheels.
- mixmastamyk 10y ago
  No sense? What if you are happy with the current version and don't plan on changing it before changing the OS? What if you don't install more than one app on a system, or are using containers? Then you might not need the extra complexity.
  - klodolph 10y ago
    Even then. Suppose you want to change the OS for some reason. LTS eventually ends, maybe you want to change out some common library, or whatever. It's nice to have the option.
    - mixmastamyk 10y ago
      You could do it when you need it, ala YAGNI.
sp332 10y ago
Is it that much more work to type "python3" ?
- dyeje 10y ago
  What's the incentive? How discoverable is that? As someone not familiar with Python, I certainly would never guess to type 'python3'.
  - deleted 10y ago
    [deleted]
  - sp332 10y ago
    Python 2 and python 3 are not the same language. There are big breaking changes between them. Most distros kept "python" pointing at python 2 to avoid breaking old scripts. If you want Python 3, you have to ask for it.
    - xapata 10y ago
      Yes, there is a breaking change. No, they are still essentially the same language.
      - sp332 10y ago
        I mean it's a different binary with a different interpreter.
  - mixmastamyk 10y ago
    If you are not familiar with it, why are you running the interactive interpreter? If you are running someone else's script, they will have chosen python3 for you if it is a requirement.
  - zokier 10y ago
    Distros are dropping/have dropped python2 from default install. So incentive is that py3k is available out-of-the-box while you need to install py2 separately. As for discoverability, typing pyt<tab><tab> is probably what most people would do and that discovers python3 just fine.
d0m 10y ago
You still need to pick your linux distro.. and they aren't all running the same version. E.g. archlinux symlinks python to python3.
johnny22 10y ago
python will probably always run python2. if you wanna see if python3 is installed, then type python3.

It is pretty simple: when I spin up an EC2 instance on amazon, and I type "python" in the console, whatever version that is will be the version I use.

by skizm 10y ago

It is pretty simple: when I spin up an EC2 instance on amazon, and I type "python" in the console, whatever version that is will be the version I use.

lima 10y ago

Nowadays, I no longer use the distribution Python at all. Debian Stable and pyenv it is. That way, I have a rock solid operating system and my application are completely decoupled. Using distribution packages for application deployments is insane. It makes sense for workstation or systems software where the application you develop is part of the operating system, but for a server application, it makes no sense at all.

snuxoll 10y ago
I use distribution packages for all my deployments, period. I have no desire to maintain a separate system for installing an upgrading my own applications versus those provided in repositories already. Time to push out a new release? `tito release koji-el7`, SRPM built and sent to Koji to be built and packaged, every 15 minutes mash runs to update our internal yum repo from Koji - and next time Puppet runs the package is automatically upgraded to the latest version without me having to do anything. No virtualenv's, no tarballs, nothing special beyond an RPM. I won't deploy software any other way (and if something doesn't already have an RPM I will make one for it).
- kstrauser 10y ago
  Note to self: snuxoll likes pushing boulders up hills by ignoring all the tooling people have invented to make this stuff easy.
  - snuxoll 10y ago
    > ignoring all the tooling people have invented to make this stuff easy. I don't, I just use the standard one that comes with the operating system instead of insisting on re-inventing the wheel because "packaging is hard". I could have just had tito push directly to a yum repository if I so desired, but it's much nicer to use Koji (which I'm already familiar with).
    - kstrauser 10y ago
      > I don't, I just use the standard one that comes with the operating system ...which is "ignoring all the tooling people have invented to make this stuff easy". virtualenv and pip were explicitly designed to work around two damn nigh insurmountable problems: 1) OS vendors move slowly, and 2) Sometimes two projects on the same machine need two different libraries It's trivial to use virtualenv and pip to make Project A and Project B run side by side with different Python versions and completely different dependency manifests. You can come up with your own ad-hoc system to deal with this or you can adapt the best practice of every other Python shop. Make no mistake though: your current way is deliberately choosing the hard road.
      - snuxoll 10y ago
        virtualenv is trying to solve a problem that's already solved by setuptools and eggs, and doing a shitty job at it. Back before eggs where a thing, sure, virtualenv had a purpose - but now there's absolutely no need to create a completely independent environment when you can just use pkg_resources.require() or just add the appropriate eggs to sys.path. Virtualenv doesn't make my life any easier, it makes deploying applications harder since I have to write a custom deployment pipeline - whereas I already maintain RPM's for other non-python software we use internally, and I can use the same infrastructure to handle them both. Edit: For most of our applications the latest Fedora Server release is also our target host, so "distributions moving slowly" is rarely an excuse as typically the latest packages are available (and if not we make them ourselves, like we do for selenium).
        takeda 10y ago
        You have mixed up history line. Eggs are older than virtualenv, from the times of easy_install. Now there are wheels that are nicely integrated with pip. Also virtualenv became integrated into python (it's called pyvenv now).
      - anamoulous 10y ago
        Another option here is to pin your Python version to whatever Anaconda is. It's very easy to install and use Anaconda in production.
- takeda 10y ago
  https://ius.io/ https://ius.io/ is your friend. Among many things you have all versions of python available that don't conflict with system packages or themselves. What's awesome is that you can install multiple versions and all of them just work.
matt_wulfeck 10y ago
They aren't completely decoupled. Even with a virtenv you still need to install and maintain a lot of library and header packages on the host OS.
- lima 10y ago
  Well, almost completely. The build dependencies don't change nearly as fast as the application, and are generally backwards compatible.
- Filligree 10y ago
  For complete decoupling, better use NixOS.
  - lima 10y ago
    Or Docker containers :-)
- takeda 10y ago
  That's problem which is solved with wheels.
mixmastamyk 10y ago
No sense? What if you are happy with the current version and don't plan on changing it before changing the OS? What if you don't install more than one app on a system, or are using containers? Then you might not need the extra complexity.
- klodolph 10y ago
  Even then. Suppose you want to change the OS for some reason. LTS eventually ends, maybe you want to change out some common library, or whatever. It's nice to have the option.
  - mixmastamyk 10y ago
    You could do it when you need it, ala YAGNI.

sp332 10y ago

Is it that much more work to type "python3" ?

dyeje 10y ago
What's the incentive? How discoverable is that? As someone not familiar with Python, I certainly would never guess to type 'python3'.
- deleted 10y ago
  [deleted]
- sp332 10y ago
  Python 2 and python 3 are not the same language. There are big breaking changes between them. Most distros kept "python" pointing at python 2 to avoid breaking old scripts. If you want Python 3, you have to ask for it.
  - xapata 10y ago
    Yes, there is a breaking change. No, they are still essentially the same language.
    - sp332 10y ago
      I mean it's a different binary with a different interpreter.
- mixmastamyk 10y ago
  If you are not familiar with it, why are you running the interactive interpreter? If you are running someone else's script, they will have chosen python3 for you if it is a requirement.
- zokier 10y ago
  Distros are dropping/have dropped python2 from default install. So incentive is that py3k is available out-of-the-box while you need to install py2 separately. As for discoverability, typing pyt<tab><tab> is probably what most people would do and that discovers python3 just fine.

d0m 10y ago

You still need to pick your linux distro.. and they aren't all running the same version. E.g. archlinux symlinks python to python3.

johnny22 10y ago

python will probably always run python2. if you wanna see if python3 is installed, then type python3.