search

osuosl-cookbooks / pgd

Apache License 2.0
1 stars 0 forks source link

Look into deprecating virtualenv #7

Open pop opened 9 years ago

pop commented 9 years ago

Since we only have one virtualenv we may be able to depricate sourcing the virtualenv in the cookbook and instead just sudo pip install -r requirements.txt.

pop commented 9 years ago

At the moment this isn't breaking anything. We'll leave it as a low-hanging bug for future devs to work on.

ramereth commented 9 years ago

@ElijahCaine I really would like to keep virtualenv as a requirement. It makes application deployment so much easier. What are the exact issues from a developer point of view?

mathuin commented 9 years ago

Virtualenv creates a local instance of an arbitrary version of Python using an arbitrary set of modules as defined by the developer. In theory, any developer who creates a virtualenv from the same requirements.txt will have the same exact Python environment as the original developer intended.

This is great for the typical development environment: for example, systems which support one or more developers and for whom write access is limited to their home directories. In this case, we are creating a dedicated virtual machine and installing Python and friends as root. There's no real need for virtualenvs in that case, and they can present some confusion -- where was that package installed, et cetera.

Problems can also arise with Python packages that have non-Python dependencies (such as cairocffi) or external binaries (such as DSSP). These bits of software are not designed to work with virtualenv and thus must be shoehorned into that environment. Installing those bits of software the way their authors intended -- on the system as root -- would seem to be the right way to go in this case.

ramereth commented 9 years ago

IMO all non-python deps should be installed by chef before the virtual env gets created. Those don't need to be directly in the virtualenv. What are the exact problems with virtualenv with those external applications?

I also like the idea of keeping the application as portable as possible. Meaning, if we need to eventually put this on a shared host, we don't have to worry about installing stuff as root. I guess I would like to see some specific examples of where virtualenv is causing issues.

mathuin commented 9 years ago

The exact problem with py2cairo was that it required a local build plus root access to install the software. cairocffi, the drop-in replacement, mitigated that but still has additional dependencies. The DSSP issue can be solved by installing it as root to /usr/local/bin or wherever.

Again, it's not that stuff doesn't work with virtualenv, it's that virtualenvs aren't necessary with virtual machines. Keeping it this way is fine with me, and if we run into complications due to installation confusion or anything else we can handle them at the time instead of trying to prevent problems now.