This chapter describes other projects that are related in some way to everyapp.bootstrap. It also describes alternative projects that can provide similar functionality.
Below is a list of other projects that are related to everyapp.bootstrap. If you like this project, you may also find these others useful as well.
virtualenv “is a tool to create isolated Python environments.”
everyapp.bootstrap is really just some customizations on top of it.
Paver “is a Python-based build/distribution/deployment scripting tool along the lines of Make or Rake.”
It includes support for creating customized virtualenv bootstrap scripts. In fact, everyapp.bootstrap‘s creator, Krys Lawrence, has used Paver very successfully for years. Paver is the inspiration for creating everyapp.bootstrap.
Below is a list of other projects that provide the same or similar functionality. If everyapp.bootstrap does not meet your needs, perhaps one of these other projects will.
virtualenv “is a tool to create isolated Python environments.”
While everyapp.bootstrap uses virtualenv to create virtual environment bootstrap scripts, you can use virtualenv directly to create your customized bootstrap scripts. What everyapp.bootstrap adds are the enhanced features like configuration file support and installation of additional packages.
Paver “is a Python-based build/distribution/deployment scripting tool along the lines of Make or Rake.”
It includes support for creating customized virtualenv bootstrap scripts that can install additional packages and run additional commands. However, until recently (2010-11-11) Paver has been only minimally maintained and has not kept up with newer virtualenv developments. Also, Paver is less flexible than everyapp.bootstrap in it’s virtualenv customizability and it’s virtualenv support cannot be separated from the rest of the Paver tool. It was for these reasons that everyapp.bootstrap was created. That said, Paver is an excellent tool and the closest alternative in spirit to everyapp.bootstrap.
pyutilib.virtualenv “includes the vpy_create script, which is used to create virtualenv bootstrap scripts that automate the installation of virtualenv along with other Python packages.”
Like everyapp.bootstrap, it includes support for a configuration file and installing additional packages. However, it also seems more complex. It seems to create several additional directories and seems to have a greater focus on Subversion checkouts. everyapp.bootstrap seems to be a simpler, more direct customization of virtualenv.
envbuilder “is a system for automatically building virtualenvs in Python. To do this, it uses a .env config file to define parcels, which are individual pieces of software to be checked out and installed into the virtualenv.”
envbuilder seems like it does similar things as everyapp.bootstrap, however, it is lacking in documentation and like pyutilib.virtualenv, seems to have a greater focus on Subversion checkouts. Also, the concept of parcels and the format of it’s .env files are more complex than the more direct customizations to virtualenv that everyapp.bootstrap provides.
virtualenvwrapper.project “is a plugin [sic] for virtualenvwrapper to extend its project-management features. Where virtualenvwrapper is for managing virtualenv environments, project manages your development source directories.”
Through the use of it’s template system, you could use virtualenvwrapper.project to build a customized development environment for a project. However, virtualenvwrapper does not work on Windows and building/integrating a template into your project as a bootstrap script would likely be more complicated than using everyapp.bootstrap. everyapp.bootstrap is more focused on being part of your project in order to create reproducible development environments. virtualenvwrapper.project seems to have a more external-to-your-project focus.
The zc.buildout “project provides support for creating applications, especially Python applications. It provides tools for assembling applications from multiple parts, Python or otherwise. An application may actually contain multiple programs, processes, and configuration settings.”
zc.buildout provides an alternative to virtualenv for creating isolated Python environments. Like everyapp.bootstrap it supports using a configuration file and installing additional packages. It can also do a lot more. On the other hand, it does not use virtualenv and is more confusing to use. It is commonly used in automated deployment scenarios, whereas everyapp.bootstrap focuses more on reproducible development environments.
rjm.recipe.venv “is a simple zc.buildout recipe that will use the virtualenv package to turn the buildout root into a sandboxed virtual python environment. It is especially useful in conjunction with gp.recipe.pip, which can then be used to install python packages into the virtualenv that has been created.”
rjm.recipe.venv, along with gp.recipe.pip and zc.buildout could be used together to achieve much of the enhanced capabilities of everyapp.bootstrap. However, that is a much more complex setup and seems redundant once you are already using zc.buildout. Also, not all packages can be installed with pip, especially on Windows, which is why everyapp.bootstrap includes support for easy_install.
BPT “is a Python library (bpt) and a command line application (box) to create and manage isolated enviroments [sic], or boxes. [...] BPT is similar in some ways to virtualenv, but it is not restricted to Python packages, allowing to install [sic] virtually any Unix software.”
It seems like you could use BPT to create isolated Python environments, like virtualenv does, along with the installation of additional packages and the running of additional commands. However, BPT does not use virtualenv and does not include support for Windows. It also seems more complex because of it’s broader scope. everyapp.bootstrap is simpler and more focused on development environments for Python projects.
Enter search terms or a module, class or function name.