
Pundle - bundler for python
I'll start with the PR of another project that I really like to use - pyenv. This is the rbenv port for python, which serves to install the necessary versions of python into the user’s folder in the bowels of ~ / .pyenv, and activate the desired 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 Bundler (http://bundler.io/), and called it Pundle. This is the second part of the workflow associated with versions of interpreters and packages in rubles, and like the first, it 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 the packages in directories like .pundlerdir / python-version-variant / package-name-2.3.4, and when the project starts , 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 when expanding .pth files into site-packages, but it works fine with normal options. And their overwhelming majority, well, about the cunning ones have time to figure out how to deal with them.
So, let's play around:
Great, the right version of the interpreter! You have already begun to switch to the third version in order to reverse the tendency towards the slow dying of the language? Then we go further, breathe more novelty and create a requirements.txt file with the contents:
Well, now run pundle:
At this point, we delivered the packages and received the frozen.txt file.
We got two packages that we wanted, and a couple to the load as nomad dependencies (also a good thing , but Sasha burns about it better).
Further, we have two options - the first is in the file, with which we plan to launch our project with our hands to import pundle and ask it to activate the necessary versions of the projects.
I prefer the fixate command to add activation of the necessary package versions to usercustomize.py:
From now on, we can start the interpreter and automatically have access to the necessary package versions:
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 deployment. On the server, it makes no sense in five pythons and seven djangos.
I enjoy using both projects in real work, and I really like not to mess with virtualenv and interpreter versions. But I’m a little bored of using pundle alone, so I took up the PR and I invite everyone to change the workflow of modern pythoner to a new and advanced one.
Following this good old tradition of sharing sound ideas with the ruby community, I decided to port the idea of Bundler (http://bundler.io/), and called it Pundle. This is the second part of the workflow associated with versions of interpreters and packages in rubles, and like the first, it 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 the packages in directories like .pundlerdir / python-version-variant / package-name-2.3.4, and when the project starts , 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 when expanding .pth files into site-packages, but it works fine with normal options. And their overwhelming majority, well, about the cunning ones have time to figure out how to deal with them.
So, let's play around:
> brew install pyenv > pyenv install 3.4.1 > pyenv shell 3.4.1 > python --version Python 3.4.1
Great, the right version of the interpreter! You have already begun to switch to the third version in order to reverse the tendency towards the slow dying of the language? Then we go further, breathe more novelty and create a requirements.txt file with the contents:
trafaret> 0.5 nomad> 1.8
Well, now run pundle:
> pip install pundle ... > python -m pundle Install some packages ... many beeches, characters, interjections, meditation
At this point, we delivered the packages and received the frozen.txt file.
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 got two packages that we wanted, and a couple to the load as nomad dependencies (also a good thing , but Sasha burns about it better).
Further, we have two options - the first is in the file, with which we plan to launch our project with our hands to import pundle and ask it to activate the necessary versions of the projects.
I prefer the fixate command to add activation of the necessary package versions to usercustomize.py:
> python -m pundle fixate
From now on, we can start the interpreter and automatically have access to the necessary package versions:
> 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 deployment. On the server, it makes no sense in five pythons and seven djangos.
I enjoy using both projects in real work, and I really like not to mess with virtualenv and interpreter versions. But I’m a little bored of using pundle alone, so I took up the PR and I invite everyone to change the workflow of modern pythoner to a new and advanced one.