Package: xe
xestands for eXecutable Environment.There are a ton of “best practices” for python projects. We can all
agree that you should use avirtualenvand a test runner such aspytestornose.Pipis another good tool to use.Sphinxis great
for documentation. The list goes on.The problem is that while we agree on the tools, we seldom agree on
how we should use the tools. Some people usevirtualenvwrapperand
prefer to hide all their virtualenv’s in a hidden directory. Others
prefer to create a directory within the project root. Others like to
do avirtualenv .to create a virtualenv for a project so activation
does the “Right Thing” with the prompt and uses the project name. Not
to mention tools liketoxthat help create virtualenvs for different
versions of Python and make sure your dev environment doesn’t mix with
your test environment.While I’m positive that I can’t bring the Python world together in
harmony, I can write a tool to make this sort of environment
management and automate my own standard practices. I’m calling this
toolxe.Project Opinionsxeis slightly opinionated in decisions it makes regarding a
project’s dev environment. These opinions are never meant to be
controversial! In fact the goal is to be as benign as possible in
hopes thatxewill easily support any developer’s workflow.With that in mind, there are some ideals thatxetries to maintain
in order to be general and easy to work with.all commands should be runnable without a required “activation”
stepa project should have its own environmentAvoiding ActivationIf you’ve ever deployed a project only to realize that you failed to
update a dependency, then there is a good chance you were bitten by a
fragile environment. While it is handy to be able to “activate” your
environment, it makes it really easy to miss things when you are
updating dependencies.Xe explicitly avoids shell level activation and instead finds your
virtualenv on every command.The Right Environment for Every CommandAnother areaxehelps is when you use an IDE type tool. Most editors
and IDEs have the idea of a project. In the project settings you can
configure builds that typically map to running tests or project
tasks. If you are using a non-virtualenv aware tool, you usually have
to configure environment variables in order to make sure the correct
virtualenv is used. Even if your tool does understand virtualenvs, you
still need to supply some configuration to the correct environment.Usingxeyou can easily configure the default build asxe test
$fn. There is not a list of environment variables you have to setup
and configure. You don’t have to specify a virtualenv directory or
testing tool. You can letxetakes care of it.Isolating Your EnvironmentA project should have its own environment because you should be
testing and using that project in isolation. That doesn’t mean you
shouldn’t have subrepos or install other packages as editable. It
simply means that if you are working in a project directory, you
should be using that project’s environment.Along similar lines, a project environment should be easy to delete
and rebuild from scratch. Usingxe, the default behavior is to
create a directory local virtualenv that can be removed and rebuilt
from scratch when necessary.Standard Project Files and DirectoriesHere are the standard project files and directories thatxeutilizes.setup.pyrequirements.txtdev_requirements.txtvenv/ (virtualenv directory)Most of these can be configured to point to other non-root
directories, but if you use these files,xewill try to work out of
the box without extra configuration.It would be nice to eventually support different build tools, but I
imagine that will be implemented via plugins. The idea being that an
organization could implement their own build entry points and usexeto run them correctly.Getting StartedTypically you’d read this first, but as this is our code we’re talking
about we needed to get the prereq’s out of the way and make sure that
your project isn’t going to get borked byxe. Assuming things look
reaonable, you can get started by doing:$ xe bootstrapxewill create a virtualenv if one hasn’t been created yet. It will
then look for adev_requirements.txtand run that in the newly
create environment. From there you can usexeto run tasks. A good
default is simply running python:$ xe pythonThat will start up the python in thexevirtualenv. If you are using
a django project you can use the following shortcut to have access to
yourmanage.pycommands:$ xe manage runserverIf you use pytest, you can run your tests too:$ xe test -xSay you build your docs with make, you can usexeto run make and be
confident your environment will be in place.$ xe make htmlWorking with Virtual MachinesAnother concept of an environment is to work on a remote machine or
virtual machine such asVagrant.xesupportsrdofor running
commands on remote machines.To userdofor all commands, add to your.xerc:USE_RDO:trueIf you only want to userdofor specific commands, specify them via
theRDO_COMMANDSfield:RDO_COMMANDS:-make-python