{paas}ify not identifying Flask app

[gilzow]

As mentioned in my other issue ( #128 ) i'm trying to {paas}ify my flask app. I know we're using the presence of requirements.txt to determine a Pip dependency manager but there's an issue with using the contents of the requirements.txt file to determine the stack.

It seems that it is fairly common for flask (maybe many python?) apps to have a requirements.txt file in a project root that require other requirements.txt files. In the case of the one I've been testing, the contents of the root requirements.txt is:

# Included because many Paas's require a requirements.txt file in the project root
# Just installs the production requirements.
-r requirements/prod.txt

and the true requirements are in the prod/dev.txt files inside of the requirements directory.

[gilzow]

oh, and I'll add that because it can't determine the stack correctly, it then fails to identify the runtime correctly since we're using the stack to determine the runtime.

[gilzow]

Was speaking to @chadwcarlson about this issue. Given that requiring other requirement files is a fairly common practice in python, and that there aren't any other consistent methods to fingerprint/identify a flask app, we may need to consider alternatives to identifying a flask-based project.

One idea (at least for the MVP) is that if {paas}ify is unable to detect the stack, we prompt the user and ask them if they are deploying any of the following, and then give them a list of the 6 stacks + "other". If they choose one of the 6 we can then set detection to that stack manually. Additionally, we can then ask for the dependency management file they're using since we were unable to ID the stack initially.

If they select "other" then we can continue the current flow where we ask the user for the runtime.

The reason we're suggesting asking them about the stack first, before the runtime, is based on the what we believe is the current flow in the code. Once we're past the MVP, and especially as we begin to add more stacks, we may need to rethink the order.

[chadwcarlson]

@akalipetis curious with your take here. Flask really seems like the odd one out, and potentially many places where this requirements.txt file might be.

[akalipetis]

It's a bit complicated, on one hand, we want to limit questions as much as possible, while on the other I understand that there might be cases where we'd like to allow the user to make a few choices.

If we can't detect the stack, the user can still select their runtime, so I don't believe this to be a big blocker - if they don't follow the common practices we identify, they can continue to a generic project creation flow which guides them through the different steps, like runtime selection.

I believe this is OK for the MVP, but we could further enhance it by allowing the user to select their package managers if we can't detect any. How do you feel about that?

[gilzow]

I think for the MVP we will have to add more documentation then for the Flask stack. Not a problem; we can do that.

HOWEVER, moving forward, we're definitely going to have to address this issue in some way. Python doesn't require requirements.txt to be in any specific place, supports requiring other files from inside a requirements file, and the requirements file itself doesn't have to be a specific name.

As an example of what I'm talking about is this Django template:
https://github.com/render-examples/django-quick-start/blob/master/requirements/production.txt

Its requirements file is named production.txt and is in a subdirectory (that just happens to be named requirements but doesnt have to be). In addition, it requires the file base.txt and it's in that file where the Django framework is actually required. It's entirely plausible that someone using this template and migrating to us could add a requirements.txt file in the root of the project, that file requires requirements/production.txt which requires base.txt. In fact, here's an example Django project that does exactly what I described: https://github.com/jambonrose/python-web-dev-21-2/blob/class_material/requirements.txt

While in this specific example, we could luck out in matching either on the # Django comment or Django-related requirements in requirements/production.txt, we can't reliably count on that type of luck.

Similarly, we're using the presence of settings.py and manage.py to determine the Django stack. However, there is no specific requirement for Django to use the file names settings.py or manage.py. While they're certainly a common practice in the Django space, you can rename either of them. In the example I linked above, settings are located in a settings package and not in a settings.py file so we would fail to detect this example as a Django stack.

Similarly, manage.py doesn't have to be named manage.py and while uncommon, can be anything you want.

Again, for the MVP, we have to move forward with what we have. But given the above, we're going to need to rethink our {paas}ify strategy for all python-based frameworks we want to support.

[gilzow]

ok, some more feedback in regards to flask. Was testing out a flask based starter kit. It uses SQLAlchemy which requires the database dialect name to start the DATABASE_URL environment variable. SQLAlchemy uses postgresql keyword for postgresql databases. Unfortunately, in the auto-generated .environment file we use the scheme property of the relationship which, for postgresql is pgsql. This cause the deployment to fail with an "unknown dialect` error message.

Given the ubiquity of SQLAlchemy in the python space, we may need to consider switching how we construct the DATABASE_URL parameter for flask apps, and perhaps many python-based applications, when a postgres service is added.