~roadmr/canonical-identity-provider/charm-git-minideploy

« back to all changes in this revision

Viewing changes to lib/virtualenv-tools/virtualenv_tools.egg-info/PKG-INFO

  • Committer: Simon Davy
  • Date: 2015-01-23 13:42:38 UTC
  • mto: This revision was merged to the branch mainline in revision 46.
  • Revision ID: bloodearnest@gmail.com-20150123134238-qdt45uaz67gcegri
bundle virtualenv-tools in the charm

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
Metadata-Version: 1.1
 
2
Name: virtualenv-tools
 
3
Version: 1.0
 
4
Summary: A set of tools for virtualenv
 
5
Home-page: http://github.com/fireteam/virtualenv-tools
 
6
Author: Fireteam Ltd.
 
7
Author-email: support@fireteam.net
 
8
License: UNKNOWN
 
9
Description: 
 
10
          -- virtualenv-tools
 
11
        
 
12
             This repository contains scripts we're using at Fireteam for our
 
13
             deployment of Python code.  We're using them in combination with
 
14
             salt to build code on one server on a self contained virtualenv
 
15
             and then move that over to the destination servers to run.
 
16
        
 
17
             Why not virtualenv --relocatable?
 
18
        
 
19
               For starters: because it does not work.  relocatable is very
 
20
               limited in what it does and it works at runtime instead of
 
21
               making the whole thing actually move to the new location.  We
 
22
               ran into a ton of issues with it and it is currently in the
 
23
               process of being phased out.
 
24
        
 
25
             Why would I want to use it?
 
26
        
 
27
               The main reason you want to use this is for build caching.  You
 
28
               have one folder where one virtualenv exists, you install the
 
29
               latest version of your codebase and all extensions in there, then
 
30
               you can make the virtualenv relocate to a target location, put it
 
31
               into a tarball, distribute it to all servers and done!
 
32
        
 
33
             Example flow:
 
34
        
 
35
               First time: create the build cache
 
36
        
 
37
                 $ mkdir /tmp/build-cache
 
38
                 $ virtualenv --distribute /tmp/build-cache
 
39
        
 
40
               Now every time you build:
 
41
        
 
42
                 $ . /tmp/build-cache/bin/activate
 
43
                 $ pip install YourApplication
 
44
        
 
45
               Build done, package up and copy to whatever location you want to have
 
46
               it.
 
47
        
 
48
               Once unpacked on the target server, use the virtualenv tools to
 
49
               update the paths and make the virtualenv magically work in the new
 
50
               location.  For instance we deploy things to a path with the
 
51
               hash of the commit in:
 
52
        
 
53
                 $ virtualenv-tools --update-path /srv/your-application/<hash>
 
54
        
 
55
               To also update the Python executable in the virtualenv to the
 
56
               system one you can reinitialize it in one go:
 
57
        
 
58
                 $ virtualenv-tools --reinitialize /srv/your-application/<hash>
 
59
        
 
60
            
 
61
             Compile once, deploy whereever.  Virtualenvs are completely self
 
62
             contained.  In order to switch the current version all you need to
 
63
             do is to relink the builds.
 
64
        
 
65
        
 
66
        
 
67
Platform: UNKNOWN
 
68
Classifier: License :: OSI Approved :: BSD License
 
69
Classifier: Programming Language :: Python