2

So I have a flask app under development using virtualenv. I have a tree like this:

./app - view, model, etc
./flask - virtualenv

Obviously app is managed by git. My question is: should I do the same with flask?

lang2
  • 11,433
  • 18
  • 83
  • 133
  • 1
    Ideally, you save the requirements of the project to a requirements.txt file which you add to version control. You can do that with `pip freeze > requirements.txt` . This is so that you wouldn't be checking in large packages into version control. – Bhargav Jun 15 '15 at 13:50
  • I don't suggest using `pip freeze`. It outputs installed packages, maybe some of them we don't use at all; some of them will be installed by other packages(jinja2 will be installed if you want to install flask), so don't have to include them all. – lord63. j Jun 15 '15 at 13:59
  • @lord63.j I generally include a `requirements.txt` for *other developers* (i.e. including things like `pylint`, `Sphinx`), but specify the packages the *end users* need, either to `install` or `test`, in `setup.py`. If you're developing in a virtualenv, `pip freeze` will only be the packages you're using **for that project**, which makes life easier. – jonrsharpe Jun 15 '15 at 14:03
  • @jonrsharpe `pip freeze` outputs installed packages. If we use libA and then we change to use libB, unless you uninstall libA, or it will be in the `requirements.txt`; how about some packages that we just want to have a try, say we tried nose and then find pytest, and finally use pytest. So, I mean use `pip freeze` may contain some unnecessary packages. – lord63. j Jun 15 '15 at 14:18
  • @lord63.j that's true, but it's just a matter of keeping your virtualenv up-to-date with what you're actually using, and if it's only for other developers it's not such a big deal if there are a few packages they don't really need. – jonrsharpe Jun 15 '15 at 14:28
  • A sweet alternative to `pip freeze` is [pipreqs](https://stackoverflow.com/a/31684470/3987895). – user_ May 30 '19 at 19:00

1 Answers1

10

No, you don't put anything you can instead easily generate into the repository. And virtualenvs are tied to your system; you could not re-use it on another.

Store the requirements.txt file and a README showing how to create the virtualenv in git, and every time you need to set up for development on a new machine, create the virtualenv from scratch.

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343