why lock so many pkgs to OLD versions in requirements.txt?

[xguse]

For example:

• flask-admin==1.1.0 (Current: 1.4.2)
• wtforms==1.0.5 (Current: 2.1)

I understand locking these in your own dev environments perhaps, but does your code REALLY not work with libraries as much as a full major version more recent?

That seems like a flask-diamond problem that scares me.

Thoughts?

[brennv]

We could slim down, running pipreqs we see:
setuptools==36.2.0
alembic==0.9.3
docutils==0.14rc2
flask_admin==1.5.0
flask_assets==0.12
flask_celery==2.4.3
flask_debugtoolbar==0.10.1
flask_mail==0.9.1
flask_marshmallow==0.8.0
flask_restful==0.3.6
flask_security==3.0.0
flask_sqlalchemy==2.2
GitPython==2.1.5
Pygments==2.2.0
SQLAlchemy==1.2.0b1
WTForms==2.1

[demospace]

With minor modifications all of the latest libraries can be used.

import Celerey from flask_celerey becomes simply "... from celery"

Changes to flask_security require the following addition in init_administration() of your app (along with necessary imports):

        security = application.app.extensions['security']
        @security.context_processor
        def security_context_processor():
            return dict(
                admin_base_template=admin.base_template,
                admin_view=admin.index_view,
                h=admin_helpers,
                get_url=url_for
            )

A few old-style flask.ext imports need to be updated. Seems to be working with all the latest libraries for me. Unfortunately I did this all ad hoc so I can't recall all the changes, but there weren't many.

The big one was the security context...

[LimpingNinja]

@demospace - Pull request incoming?

[demospace]

If I wasn't such a hack I would have figured out how to do that properly by now. Instead I just make changes as I go and there are many I'm sure no one else will want.

If you have detailed instructions on how to setup the PR with just my pip installed version of the lib, then I will try to pull out my idiosyncratic customizations and submit the PR...