Create a virtual environment. This is a contained workspace where you can install packages and libraries. It is useful in order to keep track of external dependencies, avoid version conflicts, and it provides handy tools to share your workplace with others or install it somewhere else later on. Read more in the [wiki ⛄︎](https://git.xpub.nl/manetta/flask-example/wiki/venv)!
This will create a virtual environment in a folder called `venv`.
Note that the first `venv` is the command, the second `venv` is the name of the folder.
Once the virtual environmnent folder has been created, you need to activate it. There are different ways to do it, depending on your operative system. (we are at the terminal)
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
* Running on http://127.0.0.1:3000
Press CTRL+C to quit
```
If you now open your browser and navigate to [http://127.0.0.1:3000](http://127.0.0.1:3000), and ta daaaa, the flask application is here!
The address `http://127.0.0.1` is actually the address of your machine, also known as `localhost`. If you try and change the url into `localhost:3000` the result should be the same!
Keep in mind that, even if you are seeing it in a browser, this is actually running locally. It is not online!
## Going online
When you want to publish the Flask app online, the easiest way to do it(and manage your project) is to use git to keep in sync with your local project.
For that you can create a new repo and follow the guided steps to push your app there.
There are plenty of ways to put your flask app online.
Here in XPUB we mainly work with small self-hosted servers like the Soupboat and the Breadcube.
These steps refer to this kind of setup.
### .gitignore
When working with git, it could happen that you don't want to push all your files in the repository. That is the case for example with the `venv` folder, of for other files related to your configurations such as `.env` files, API keys, passwords, etc.
To manage what is going to be pushed or not you can use a `.gitignore` file.
In this specific example we are gonna ignore the virtual environment and its contents, as well as some [annoying hidden files](https://en.wikipedia.org/wiki/.DS_Store) generated by our dear machines.
```
venv/
.env
.DS_Store
```
There are some `.gitignore` templates online.
You can find some here: [A collection of .gitignore templates](https://github.com/github/gitignore). Which one to use is related to the kind of project you are working on.
### .env
Your computer and the server are different machines, and they could require different configurations. The port where you are running the local application could not be available in the server. Or you would need to add a prefix to the URL to make it works.
For example to work in the Soupboat your routes must begin with `/soupboat/flask-example`, while in the Breadcube `/breadcube/flask-example`, etc.
<!-- TODO: image for variable names, in this case 'flask-example' -->
It's not handy to keep these variables in the code, because then you need to change it every time when you want to run the app in a different environment.
So, it's a good idea to separate things:
-_What stays the same_
Ideally the code is the same both in your local app and in the one online.
-_What changes_
the environmental variables: port, url prefix, debug mode, you name it
So here an `.env` file could come in handy.
This example is designed in a way that doesn't require an `.env` file on your local version, because the default values should be fine.
However in the server you will probably need to create one to adjust the url prefix and the specific port number where to run the app.
Here are the variables we are using, __BUT__ keep in mind that your values will probably be different!
```
URL_PREFIX=/soupboat/flask-example
PORT=3000
```
### Generate requirements.txt
(or maybe this happens in the beginning ??????? let's see)
