5 ms·

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

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....

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....