Virtualenv config

[ajayns]

What virtualenv config are you using? @therohitramesh

[therohitramesh]

15.0.1 @ajayns

[ajayns]

The usual configuration for Python development is not this.

You setup a virtualenv to folder or so maybe and add it to .gitignore. That'll be your local development environment, just yours and not for any other system. Then you pip freeze to requirements.txt to save all the dependencies as a list. A new user cloning your repo will setup his own dev env and install dependencies using this.

Comparing it to NodeJS, pip is npm, requirements.txt is package.json, and your virtualenv is node_modules.

So unless you're using some other configuration which is specified by the tutorial you are following or any community, this is the usual setup afaik. @therohitramesh

[therohitramesh]

I didn't set up a virtualenv folder as such. My project directly opens into it. Virtualenv can be run directly from here. This is what I understood when I compared the tutorial with the articles I read.

The rest of the details is what you said is correct except for node_modules being the NodeJS equivalent of virtualenv. I reckon that they are completely different. @ajayns

[ajayns]

I didn't mean equal in the literal sense but by usage. virtualenv makes a copy of python and allows packages to be installed to it locally via pip. This is basically what node_modules is except it doesn't add a copy of node redist, but just the packages.

About why I didn't recommend using it directly is cause Linux hardcodes all the paths and so on in the virtualenv you've created and so it may not be usable in some else's machine. @therohitramesh

[therohitramesh]

But the source of the virtualenv is in bin, right? Could you try it out and if it doesn't work then suggest a way to fix it? @ajayns

[ajayns]

Virtualenv also sets up it's own folder for it's dependencies, that's the extra folders you see. It basically helps have a local installation of python with whatever packages you require. And since the paths are hardcoded, it won't usually work in other machines.

There are multiple approaches that's why I mentioned use the one your tut or so mentions. The usual approach as I've mentioned is:

• Install virtualenv to a folder, usually env. (This is already in the default .gitignore for python projects, so it's a commonly used name)
• Make a list of all your dependencies used and save it as requirements.txt in the root. pip freeze requirements.txt would do the trick.

That'd be enough for a new user to start the project the way he likes. He can setup his own virtualenv, and for packages, he can just pip install from the requirements.txt. Now do you get how env and node_modules are similar?

[therohitramesh]

Ahh, I think I understood where I went wrong. The tutorial I followed has its code in this repository.

The way it is organized itself is wrong I think because on cloning it I wasn't able to pip install requirements.txt because the main project along with the requirements.txt was present in the folder "src". This is the exact same thing that is wrong with my project as well, right?

And yeah now I see the similarity you were talking about.

I tried fixing the thing; just see if it works. I moved requirements.txt and added a virtual environment folder "venv". I was still not able to install using requirements.txt. I had to use pip install --upgrade -r requirements.txt to make it work. @ajayns

[ajayns]

@therohitramesh See that's not a wrong form of organizing the project but an alternate way. You need to know which folder they use as source, here the project is supposed to start at src so they expect you to start a virtualenv in src and pip install there.

Add venv to .gitignore. New users don't need your virtualenv as I mentioned hardcoded paths.

So a new user:

• Create a new virtualenv
• Activate it by a command something like source bin/activate (I don't remember exactly)
• Then pip install -r requirements.txt to add packages to the virtualenv python
• You should be able run the Django app then