7 ms·

Package management was so frustrating coming from Ruby to Python. There are so many programs, and version conflicts that I run into all the time. With gems and

Package management was so frustrating coming from Ruby to Python. There are so many programs, and version conflicts that I run into all the time. With gems and bundler, it was rare if things didn't work.

cshenton 9y ago
If you get into the habit of making a virtual environment and requirements.txt in every repo then it's smooth. Just activate the env when you're using the repo and use vanilla pip install to install dependencies. Then pip freeze them into the requirements file. It's a very similar workflow to a gemfile and bundler.
- dasil003 9y ago
  I worked on python for a few months last year, and although I didn't find anything representing a canonical description of that workflow, I did eventually come to this conclusion. The only thing was that pip freeze > requirements.txt didn't really give the same power as I was used to with Gemfile.lock and the various permutations of bundle update. I forget the specifics, but I remember being unable to get the finer points of optimistic version locking to work in a way I found acceptable. That said, I have been doing ruby since before Bundler, and I really have to take my hat off to what Yehuda and company accomplished with Bundler. It was both a technical and open source community triumph to get Bundler done, stable and covering the breadth of use cases it applies to.
- yes_or_gnome 9y ago
  You're going to have a hard time supporting multiple versions of Python that way. If I started a new package today I would target 3.4, 3.5, 3.6, 3.7-dev, and likely, 2.7. A lot of well maintained packages have different dependencies based on the exact version of Python. If you're crazy enough to support 2.6, then there will be a lot of additional packages in pip freeze. Ideally, packages would have just one set of dependencies and the packages would be version locked, but that's just not the case in the Python community.
  - gjjrfcbugxbhf 9y ago
    Just target 3.4+ then... Why would you sort 2.6 in 2017? Supporting 2.7 these days in a new package is already a bit of a wtf - Django for example drops support for it next year.
    - wdfx 9y ago
      For the industry I work in, because of this: http://www.vfxplatform.com http://www.vfxplatform.com We're still maintaining stacks on py 2.6 which predate the reference platform specs
      - gjjrfcbugxbhf 9y ago
        Ok. It looks like they also drop python 2 next year?
        wdfx 9y ago
        They plan to release the spec like that, but I'm certain on this update most studios will be lagging due to the vast amount of 2 to 3 migration work that needs to be done.
        gjjrfcbugxbhf 9y ago
        Oh well knuckle down and use six for another couple of years then. At least you're not trying to write Fortran compatible with the 77 and 90 specs....
brianwawok 9y ago
Really? Pip should be pretty straight forward. Maybe you use different libraries than I do.
- autokad 9y ago
  pip (py2) on windows is an absolute disaster. pip install numpy .... if you are using windows, using python without this website is nearly impossible: http://www.lfd.uci.edu/~gohlke/pythonlibs/ http://www.lfd.uci.edu/~gohlke/pythonlibs/
  - int_19h 9y ago
    Things are a lot better with Python 3 on Windows, and especially so with Python 3.5+. "pip install numpy" will actually work, among other things. But even for packages that don't have binary wheels and have to compile things, it's much easier now to install a compiler toolchain (it's actually a single download!), and have your Python installation just pick it up automatically.
    - pen2l 9y ago
      > Things are a lot better with Python 3 on Windows, and especially so with Python 3.5+. For one of my main applications py3 proved to be too slow. For my application I use: numpy, pil, tkinter, and subprocess (and process/produce/draw on screen images (at a rate of 120/sec)). I don't know WHY but with python2 it runs acceptably fast, on python3 it's 20% slower. This has been something common for me actually. I do tend to use py3 when doing any kind of data science though.
- wlesieutre 9y ago
  But be sure to use Pip into this year's flavor of virtual environments rather than globally, since you might have multiple projects that need different versions of the same package. And be sure to run the right version, I've seen situations where a computer had python 2 and 3 installed, somehow python3 became the default when running "python" but if you ran "pip" you'd get dumped into the old version. And if your editor has a "Run script" function, it also needs to deal with "Activate the correct environment" for whichever flavor of virtual environment you've used. Any what beginner would be confused by tutorials using all sorts of different setups (virtualenv, venv, pyenv, pipenv, virtualenvwrapper, pyenv-virtualenvwrapper)? Most of them, I think. "venv" is the newest one - shipped in the python3 package except when it's not (Ubuntu, maybe others) and doesn't make copies of the python binaries for each environment. That always seemed wasteful to me, but I suppose it was the easy way around path problems with the ecosystem not having a solution built in. I love python when I'm only using the standard libraries, but if I have dependencies it's messier to set up than I want it to be.

cshenton 9y ago

If you get into the habit of making a virtual environment and requirements.txt in every repo then it's smooth. Just activate the env when you're using the repo and use vanilla pip install to install dependencies. Then pip freeze them into the requirements file. It's a very similar workflow to a gemfile and bundler.

dasil003 9y ago
I worked on python for a few months last year, and although I didn't find anything representing a canonical description of that workflow, I did eventually come to this conclusion. The only thing was that pip freeze > requirements.txt didn't really give the same power as I was used to with Gemfile.lock and the various permutations of bundle update. I forget the specifics, but I remember being unable to get the finer points of optimistic version locking to work in a way I found acceptable. That said, I have been doing ruby since before Bundler, and I really have to take my hat off to what Yehuda and company accomplished with Bundler. It was both a technical and open source community triumph to get Bundler done, stable and covering the breadth of use cases it applies to.
yes_or_gnome 9y ago
You're going to have a hard time supporting multiple versions of Python that way. If I started a new package today I would target 3.4, 3.5, 3.6, 3.7-dev, and likely, 2.7. A lot of well maintained packages have different dependencies based on the exact version of Python. If you're crazy enough to support 2.6, then there will be a lot of additional packages in pip freeze. Ideally, packages would have just one set of dependencies and the packages would be version locked, but that's just not the case in the Python community.
- gjjrfcbugxbhf 9y ago
  Just target 3.4+ then... Why would you sort 2.6 in 2017? Supporting 2.7 these days in a new package is already a bit of a wtf - Django for example drops support for it next year.
  - wdfx 9y ago
    For the industry I work in, because of this: http://www.vfxplatform.com http://www.vfxplatform.com We're still maintaining stacks on py 2.6 which predate the reference platform specs
    - gjjrfcbugxbhf 9y ago
      Ok. It looks like they also drop python 2 next year?
      - wdfx 9y ago
        They plan to release the spec like that, but I'm certain on this update most studios will be lagging due to the vast amount of 2 to 3 migration work that needs to be done.
        gjjrfcbugxbhf 9y ago
        Oh well knuckle down and use six for another couple of years then. At least you're not trying to write Fortran compatible with the 77 and 90 specs....

brianwawok 9y ago

Really? Pip should be pretty straight forward. Maybe you use different libraries than I do.

autokad 9y ago
pip (py2) on windows is an absolute disaster. pip install numpy .... if you are using windows, using python without this website is nearly impossible: http://www.lfd.uci.edu/~gohlke/pythonlibs/ http://www.lfd.uci.edu/~gohlke/pythonlibs/
- int_19h 9y ago
  Things are a lot better with Python 3 on Windows, and especially so with Python 3.5+. "pip install numpy" will actually work, among other things. But even for packages that don't have binary wheels and have to compile things, it's much easier now to install a compiler toolchain (it's actually a single download!), and have your Python installation just pick it up automatically.
  - pen2l 9y ago
    > Things are a lot better with Python 3 on Windows, and especially so with Python 3.5+. For one of my main applications py3 proved to be too slow. For my application I use: numpy, pil, tkinter, and subprocess (and process/produce/draw on screen images (at a rate of 120/sec)). I don't know WHY but with python2 it runs acceptably fast, on python3 it's 20% slower. This has been something common for me actually. I do tend to use py3 when doing any kind of data science though.
wlesieutre 9y ago
But be sure to use Pip into this year's flavor of virtual environments rather than globally, since you might have multiple projects that need different versions of the same package. And be sure to run the right version, I've seen situations where a computer had python 2 and 3 installed, somehow python3 became the default when running "python" but if you ran "pip" you'd get dumped into the old version. And if your editor has a "Run script" function, it also needs to deal with "Activate the correct environment" for whichever flavor of virtual environment you've used. Any what beginner would be confused by tutorials using all sorts of different setups (virtualenv, venv, pyenv, pipenv, virtualenvwrapper, pyenv-virtualenvwrapper)? Most of them, I think. "venv" is the newest one - shipped in the python3 package except when it's not (Ubuntu, maybe others) and doesn't make copies of the python binaries for each environment. That always seemed wasteful to me, but I suppose it was the easy way around path problems with the ecosystem not having a solution built in. I love python when I'm only using the standard libraries, but if I have dependencies it's messier to set up than I want it to be.