Kindly refer to specific answer if this question has already been tackled.
Once the Django virtual environment has been created, where do I create the project? Are they supposed to be in different folders or the project should be within the virtual environment?
I most commonly see two patterns being used in practice and discussed here.
Some people put their virtual environment within their project. That way, when they deploy their project, the entire virtual environment is deployed along with it. That’s also how they manage their virtual environments and know exactly which environment is being used with which project.
Other people, myself being one of them, keep a separate directory for my virtual environments from my projects. The virtual environments all reside within a directory named “ve” and the projects reside in other, different directories not physically related to “ve”. By creating and deploying a separate “ve” directory, I can then deploy a variety of projects that all use that same virtual environment.
I’m not aware of anyone putting their Django project directory inside the “ve”. I’m guessing you could do it, I just haven’t seen it done.
But for the most part, the choice between these options is made on the basis of factors other than purely technical issues. Django itself doesn’t care.
2 Likes
I created my virtual environment a level above my project. This way if I have additional projects I don’t need to do all the configurations
- ReportsPortal is the GitHub repo.
- Reports and tutorials being Django projects.
- Tutorials project contains the “polls” tutorial application.
I highly recommend going through the Django tutorial here which really helped me get started with Django coming from Ruby on Rails and React based development.
1 Like
By Django not caring, could it also mean to be a good practice?
That sounds less complicated but when done this way, the moment any of your newly created projects requires any upgrade, does it not also affect the other projects? Kindly forgive me that my questions may sound a little silly but I am just confused.
By “not caring”, what I mean is that it’s not a technical issue. It’s not like one way is better or worse than the other - technically.
If you create your virtual environment (VE) inside your project, then each project has its own environment. You don’t have to worry about changes to the environment affecting other projects.
If you create your VE external to your project, then it becomes easier to create a family of projects that all share the same VE. And yes, when you change your VE, every project relying upon that VE needs to be changed along with it. (And there are cases where that is what you need to do.)
So you should be looking at this decision from the perspective of “What is going to work best for you?”
Oh, and it’s not like you’re stuck doing this one way or the other. You can create some projects with the VE inside of it, and you can create other projects with external VEs.
You can change this for your projects at any time. If you’re using an external VE, you can create a VE inside the project and use it instead. If you’re using a VE inside the project, you can delete it and start using an external VE.
You can also do both.
It just doesn’t matter.
The Django project isn’t “tied” to a VE in any way. It’s the VE that runs Django. You activate a VE - any VE, and then run Django inside of it.
1 Like
Thank you! I now got the point.
I would not recommend that, personally. What besides python -m venv venv and pip install -r requirements.txt has to be configured in a virtual environment? Nothing. With single virtual environments you’re always risking that the next package installation or update has unexpected side effects.
I would always suggest to have one virtual environment per project. And to never ship the environment with the projects to production (if you’re on Windows, you can’t do that anyway). That is why you have requirements.txt and contraints.txt, to rebuild a venv within 30 seconds.
1 Like
There are two situations where this isn’t the best solution.
If you are deploying to an environment that cannot access the internet or is not allowed to have internet access, you must deploy the ve with your project.
And, if you’re deploying to a limited-resource embedded system (think Raspberry Pi), you really don’t want to load it up with multiple environments. (I work with both situations pretty much every day - they exist and are very real.)
The only absolute statement I would make regarding this is that you must take your deployment environment into consideration when you’re planning such things.
2 Likes