8

I'm trying to import secure_filename from werkzeug.utils and it shoot an error. It works fine under my base virtual env.

code:

# Flask packages
from flask import Flask, render_template, request, session, redirect, flash, send_file
from flask_bootstrap import Bootstrap 
from flask_uploads import UploadSet,configure_uploads,IMAGES,DATA,ALL

# Systems
import os 
import sys
import json
from werkzeug.utils import secure_filename

Error:

    (absa_annotation) C02QM3FSFVH3:ABSA-annotation-tool kwunkeilau$ python3 app.py 
Traceback (most recent call last):
  File "app.py", line 4, in <module>
    from flask_uploads import UploadSet,configure_uploads,IMAGES,DATA,ALL
  File "/Users/kwunkeilau/anaconda3/envs/absa_annotation/lib/python3.7/site-packages/flask_uploads.py", line 26, in <module>
    from werkzeug import secure_filename, FileStorage
ImportError: cannot import name 'secure_filename' from 'werkzeug' (/Users/kwunkeilau/anaconda3/envs/absa_annotation/lib/python3.7/site-packages/werkzeug/__init__.py)
Jürgen Gmach
  • 5,366
  • 3
  • 20
  • 37
louis lau
  • 259
  • 2
  • 3
  • 5

3 Answers3

12

That exception looks like Flask-Uploads is trying to from werkzeug import secure_filename which should be from werkzeug.utils import secure_filename, as per your own code.

Going by the Flask-Uploads github repo this appears to have been fixed 12 months ago.

I'd try pip install -U flask-uploads in your virtual environment, to ensure the latest version.

EDIT:

As @mattficke points out, the PyPi version is dated, and there's not a more recent release on the repo. Turns out you can install directly based on a commit hash, so for the latest (at the time of writing this):

pip install git+https://github.com/maxcountryman/flask-uploads.git@f66d7dc

Or in a requirements.txt:

git+https://github.com/maxcountryman/flask-uploads.git@f66d7dc

Then pip install -r requirements.txt.

Which works wonders:

>>> from flask_uploads import UploadSet,configure_uploads,IMAGES,DATA,ALL
>>> # No Exception
v25
  • 7,096
  • 2
  • 20
  • 36
  • Although the source code in Github is active, the flask-uploads package doesn't seem to be getting published to PyPI anymore. The most recent published version is from 2016: https://pypi.org/project/Flask-Uploads/ – mattficke Jan 22 '21 at 22:32
  • @mattficke Good spot: typical! It also looks like the latest tagged release on github is from `0.2.0` from 2015, earlier than the latest pip version. However I figured out a way to install based on a commit hash, see edit. – v25 Jan 22 '21 at 22:53
  • 1
    see my answer below - there is a well maintained fork - no need to install from github or manipulate import statements. The fork is better tested, fixed a couple of bugs and one security issue. And also provides releases on PyPI. – Jürgen Gmach Apr 15 '21 at 19:59
3

Alternatively to above suggested solution, you can use the well maintained fork called Flask-Reuploaded.

You do not even have to change import statements, as it tries to stay compatible with the no longer well maintained Flask-Uploads.

See https://github.com/jugmac00/flask-reuploaded

Also, Flask-Reuploaded certainly provides uptodate packages on PyPI:

https://pypi.org/project/Flask-Reuploaded/

Jürgen Gmach
  • 5,366
  • 3
  • 20
  • 37
0

If you're just trying to run the production server, you can do as follows (I suppose you're using a virtual environment by the way). Find flask_uploads.py inside the library folder of your virtual environment (something like /lib/pythonX.X/site-packages/flask_upalods.py). Then find and comment the line:

from werkzeug import secure_filename, FileStorage

and correct the references by adding these lines:

from werkzeug.datastructure import FileStorage
from werkzeug.utils import secure_filename

That is what I did when I ran into this problem.

ptrckfc_
  • 1
  • It's definitely one of the advantages of interpreted languages, like Python, that you can alter 3rd party libraries to get yourself out of a bind. However, I don't think I would recommend the practice of altering site_packages by hand because that alteration is local to just one environment. Software rarely ever gets deployed just once. Since there is a fork available with a fix, then switching over to that is a preferable solution because installing the fixed package is an easily repeatable process, especially when the dependencies are listed in a requirements.txt file or (even better) in a p – Eiríkur Fannar Torfason Apr 04 '22 at 21:39