treyzania / vader

Venvs Done Right

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Vader

VaDeR: Venvs Done Right

So we all like Python. And PIP is pretty cool as a package manager. But something that's always pissed me off about Python's ecosystem is that PIP likes to shoot itself in the foot. Let's say program A depends on version 1.2 of package B. So we install package B version 1.2. But then we need to go run program C, and that requires version 1.6 of package B. But 1.6 isn't perfectly backwards-compatible with version 1.2, and vice-versa, and things break.

Eventually someone figure out that the best idea to deal with dependency hell is to make this cool thing called Virtual Envrionments. Most of the time our IDEs and other tools take care of making the call to source some/path/or/whatever/virtualenv to set up the evironmental variables for the current shell so that PIP knows where to install the packages, but this is messy and annoying and you have to do it for each shell and if you forget then you have a good chance of breaking things. It feels like a horribly-design bandaid to me and I know there's a better way of not shooting ourselves in the foot with configurations and environmental variables.

We have this nice envvar called PYTHONPATH for a reason, but it seems like nobody uses it outside of special situations.

How does Vader work?

Instead of doing whatever PIP feels like doing for installing packages, we wrap the invocation of Python and modify the PYTHONPATH environmental variable so that python knows where to find libraries instead of keeping them in just the same place as the Python stdlib.

You can normally invoke your Python programs using vader run ./foo.py and it should sort everything out on its own.

Configuration

Vader is capable of looking for requirements.txt files and automatically downloading them into your user's ~/.vader repository. These dependencies are a lot smarter and know not to step on eachother's toes. We collect all of them together for to figure what to set PYTHONPATH to so that python knows where to look for modules.

There's also a Vaderfile you can specify using TOML for richer configuration, which will let you use vader run directly without specifying an entry file.

Usage

  • vader pull <pyver> <name> <version> :: Downloads and extracts a specific package via PIP and installs it into the local Vader repository.

  • vader download :: Downloads dependencies so that you can run the program without downloading anything.

  • vader run [<entry>] :: Downloads dependencies and runs codegen as necessary, and runs the program. Don't need to specify an entry point if you have a proper Vaderfile.

  • vader codegen :: Runs code generation programs to build dynamic deps.

  • vader clean :: Cleans dynamic dependencies directory.

  • vader package :: Packages program, all dependencies into a ZIP file, adding a bootstrap script to run it when executed.

// TODO

More important at the top.

  • Python binary execution
  • Downloading, extracting PIP dependencies
  • Automatic dependency management via requirements.txt, etc.
  • Figuring out how to use Vaderfiles
  • Packaging modular/monolithic ZIPs, debs, etc.
  • "Installing" programs from directory directly. (into /opt, etc.)
  • Dynamic dependencies (code generation a la Swagger, etc.)

About

Venvs Done Right


Languages

Language:Go 96.4%Language:Shell 3.6%