Pundle - bundler for python

I'll start with PR of another project that I really like to use - pyenv. This is the rbenv port for python, which is used to install the necessary versions of python into the user's folder in the ~ / .pyenv subsoil, and to activate the necessary version by hand or, more correctly, through the .pyenv-version file in the project folder.

Following this good old tradition of sharing sound ideas with the ruby ​​community, I decided to port the idea of ​​the Bundler (http://bundler.io/), and called it Pundle. This is the second part of the workflow associated with versions of interpreters and packages in Ruby, and, like the first, is quite reasonable.

The main idea of ​​pundle is not to create a separate directory for each combination of package versions as in virtualenv, but instead to put all packages in a directory like .pundlerdir / python-version-variant / package-name-2.3.4, and at the start of the project , taking information from frozen.txt, activate the necessary versions of packages
')


This does not work well with packages that try to do all sorts of tricks with the deployment of .pth files in site-packages, but it works fine with normal options. And the overwhelming majority of them, well, about the cunning ones, there is time to figure out how to deal with them.

So, let's play:

   > brew install pyenv
   > pyenv install 3.4.1
   > pyenv shell 3.4.1
   > python --version
   Python 3.4.1

Great, right version of the interpreter! You have already begun to switch to the third version in order to reverse the tendency to the slow dying of the language? Then we go further, inhale more novelty and create a file requirements.txt with the contents:

   trafaret> 0.5
   nomad> 1.8

Now let's run pundle:

   > pip install pundle
   ...
   > python -m pundle
   Install some packages
   ... many beeches, symbols, interjections, meditation

At this stage, we put the packages and got the file frozen.txt.

   nomad == 1.9 # nomad << requirements file
   opster == 4.1 # opster> = 4.0 << nomad << requirements file
   termcolor == 1.1.0 # termcolor << nomad << requirements file
   trafaret == 0.5.3 # trafaret << requirements file

We received two packages that we wanted, and a pair of load as nomad dependencies (also a good thing , but Sasha better burns himself about her).

Then we have two options - the first is in the file with which we plan to launch our project with our hands to import the pundle and ask it to activate the necessary versions of the projects.

I prefer the fixate command to add activation of the required package versions to usercustomize.py:

   > python -m pundle fixate

From this point on, we can start the interpreter and automatically have access to the necessary versions of the packages:

   > python
   >>> import nomad
   >>> nomad .__ version__
   '1.9'

pyenv here github.com/yyuu/pyenv
pundle here github.com/Deepwalker/pundler

It is necessary to use it on the developer's machine, and not during the deployment. On the server, there is no sense in five pythons and seven djangos.

I enjoy using both projects in real work, and I really like not messing with virtualenv and interpreter versions. But I'm a little bored with using pundle alone, so I took up the PR and invited everyone to change the workflow of the modern pythoner to a new and advanced one.