{ "info": { "author": "Eric Larson", "author_email": "eric@ionrock.org", "bugtrack_url": null, "classifiers": [], "description": "====\n Xe\n====\n\n`xe` stands for eXecutable Environment.\n\nThere are a ton of \"best practices\" for python projects. We can all\nagree that you should use a virtualenv_ and a test runner such as\npytest_ or nose_. Pip_ is another good tool to use. Sphinx_ is great\nfor documentation. The list goes on.\n\n.. _virtualenv: http://virtualenv.org\n.. _pytest: http://pytest.org\n.. _nose: http://nose.readthedocs.org/en/latest/\n.. _pip: http://pip-installer.org\n.. _sphinx: http://sphinx-doc.org\n\n\nThe problem is that while we agree on the tools, we seldom agree on\nhow we should use the tools. Some people use virtualenvwrapper_ and\nprefer to hide all their virtualenv's in a hidden directory. Others\nprefer to create a directory within the project root. Others like to\ndo a `virtualenv .` to create a virtualenv for a project so activation\ndoes the \"Right Thing\" with the prompt and uses the project name. Not\nto mention tools like tox_ that help create virtualenvs for different\nversions of Python and make sure your dev environment doesn't mix with\nyour test environment.\n\n.. _virtualenvwrapper: http://virtualenvwrapper.readthedocs.org/en/latest/\n.. _tox: http://tox.readthedocs.org/en/latest/\n\nWhile I'm positive that I can't bring the Python world together in\nharmony, I can write a tool to make this sort of environment\nmanagement and automate my own standard practices. I'm calling this\ntool `xe`.\n\n\nProject Opinions\n================\n\n`xe` is slightly opinionated in decisions it makes regarding a\nproject's dev environment. These opinions are never meant to be\ncontroversial! In fact the goal is to be as benign as possible in\nhopes that `xe` will easily support any developer's workflow.\n\nWith that in mind, there are some ideals that `xe` tries to maintain\nin order to be general and easy to work with.\n\n 1. all commands should be runnable without a required \"activation\"\n step\n 2. a project should have its own environment\n\n\nAvoiding Activation\n-------------------\n\nIf you've ever deployed a project only to realize that you failed to\nupdate a dependency, then there is a good chance you were bitten by a\nfragile environment. While it is handy to be able to \"activate\" your\nenvironment, it makes it really easy to miss things when you are\nupdating dependencies.\n\nXe explicitly avoids shell level activation and instead finds your\nvirtualenv on every command.\n\n\nThe Right Environment for Every Command\n---------------------------------------\n\nAnother area `xe` helps is when you use an IDE type tool. Most editors\nand IDEs have the idea of a project. In the project settings you can\nconfigure builds that typically map to running tests or project\ntasks. If you are using a non-virtualenv aware tool, you usually have\nto configure environment variables in order to make sure the correct\nvirtualenv is used. Even if your tool does understand virtualenvs, you\nstill need to supply some configuration to the correct environment.\n\nUsing `xe` you can easily configure the default build as `xe test\n$fn`. There is not a list of environment variables you have to setup\nand configure. You don't have to specify a virtualenv directory or\ntesting tool. You can let `xe` takes care of it.\n\n\nIsolating Your Environment\n--------------------------\n\nA project should have its own environment because you should be\ntesting and using that project in isolation. That doesn't mean you\nshouldn't have subrepos or install other packages as editable. It\nsimply means that if you are working in a project directory, you\nshould be using that project's environment.\n\nAlong similar lines, a project environment should be easy to delete\nand rebuild from scratch. Using `xe`, the default behavior is to\ncreate a directory local virtualenv that can be removed and rebuilt\nfrom scratch when necessary.\n\n\nStandard Project Files and Directories\n======================================\n\nHere are the standard project files and directories that `xe`\nutilizes.\n\n 1. setup.py\n 2. requirements.txt\n 3. dev_requirements.txt\n 4. venv/ (virtualenv directory)\n\nMost of these can be configured to point to other non-root\ndirectories, but if you use these files, `xe` will try to work out of\nthe box without extra configuration.\n\nIt would be nice to eventually support different build tools, but I\nimagine that will be implemented via plugins. The idea being that an\norganization could implement their own build entry points and use `xe`\nto run them correctly.\n\n\nGetting Started\n===============\n\nTypically you'd read this first, but as this is our code we're talking\nabout we needed to get the prereq's out of the way and make sure that\nyour project isn't going to get borked by `xe`. Assuming things look\nreaonable, you can get started by doing:\n\n $ xe bootstrap\n\n`xe` will create a virtualenv if one hasn't been created yet. It will\nthen look for a `dev_requirements.txt` and run that in the newly\ncreate environment. From there you can use `xe` to run tasks. A good\ndefault is simply running python:\n\n $ xe python\n\nThat will start up the python in the `xe` virtualenv. If you are using\na django project you can use the following shortcut to have access to\nyour `manage.py` commands:\n\n $ xe manage runserver\n\nIf you use pytest, you can run your tests too:\n\n $ xe test -x\n\nSay you build your docs with make, you can use `xe` to run make and be\nconfident your environment will be in place.\n\n $ xe make html\n\n\nWorking with Virtual Machines\n-----------------------------\n\nAnother concept of an environment is to work on a remote machine or\nvirtual machine such as `Vagrant `_. `xe`\nsupports `rdo `_ for running\ncommands on remote machines.\n\nTo use `rdo` for all commands, add to your `.xerc`:\n\n.. code-block:: yaml\n\n USE_RDO: true\n\nIf you only want to use `rdo` for specific commands, specify them via\nthe `RDO_COMMANDS` field:\n\n.. code-block:: yaml\n\n RDO_COMMANDS:\n - make\n - python", "description_content_type": null, "docs_url": null, "download_url": "UNKNOWN", "downloads": { "last_day": -1, "last_month": -1, "last_week": -1 }, "home_page": "http://github.com/ionrock/xe", "keywords": null, "license": "UNKNOWN", "maintainer": null, "maintainer_email": null, "name": "xe", "package_url": "https://pypi.org/project/xe/", "platform": "UNKNOWN", "project_url": "https://pypi.org/project/xe/", "project_urls": { "Download": "UNKNOWN", "Homepage": "http://github.com/ionrock/xe" }, "release_url": "https://pypi.org/project/xe/0.2/", "requires_dist": null, "requires_python": null, "summary": "Reliably manage your python dev environment.", "version": "0.2" }, "last_serial": 1558383, "releases": { "0.2": [ { "comment_text": "", "digests": { "md5": "b71c6037f103b46d41c95038c0585661", "sha256": "ad97c60ce725c6eb19ab7892f207991bac11aa6c69c19905e0f568c9cc3787d0" }, "downloads": -1, "filename": "xe-0.2.tar.gz", "has_sig": false, "md5_digest": "b71c6037f103b46d41c95038c0585661", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 6718, "upload_time": "2015-05-22T18:12:10", "url": "https://files.pythonhosted.org/packages/76/08/96472ecb9641d0d84c62ef72e0948d06a782983aaf6421e37ea0813ca724/xe-0.2.tar.gz" } ] }, "urls": [ { "comment_text": "", "digests": { "md5": "b71c6037f103b46d41c95038c0585661", "sha256": "ad97c60ce725c6eb19ab7892f207991bac11aa6c69c19905e0f568c9cc3787d0" }, "downloads": -1, "filename": "xe-0.2.tar.gz", "has_sig": false, "md5_digest": "b71c6037f103b46d41c95038c0585661", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 6718, "upload_time": "2015-05-22T18:12:10", "url": "https://files.pythonhosted.org/packages/76/08/96472ecb9641d0d84c62ef72e0948d06a782983aaf6421e37ea0813ca724/xe-0.2.tar.gz" } ] }