Last modified: 2014-08-22 18:11:25 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T71852, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 69852 - upload.py: Add an option to automatically abort uploads if the file already exists
upload.py: Add an option to automatically abort uploads if the file already e...
Status: RESOLVED FIXED
Product: Pywikibot
Classification: Unclassified
General (Other open bugs)
core-(2.0)
All All
: High enhancement
: ---
Assigned To: Fabian
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-08-21 14:59 UTC by Jesús Martínez Novo (Ciencia Al Poder)
Modified: 2014-08-22 18:11 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Jesús Martínez Novo (Ciencia Al Poder) 2014-08-21 14:59:15 UTC
If we are trying to upload a lot of files and some of them already exist, it would be nice to have an option to automatically skip those uploads (because of resuming the batch upload operation, or because of manual upload of some of them)

There's still no option to do a "batch upload", but I handle it with a script that runs a list of pywikibot commands in a batch. And it gets stuck waiting for a user response when it receives a warning, which is annoying.
Comment 1 Gerrit Notification Bot 2014-08-21 15:10:05 UTC
Change 155560 had a related patch set uploaded by Martineznovo:
upload.py: Add option to automatically abort upload on warning

https://gerrit.wikimedia.org/r/155560
Comment 2 Jesús Martínez Novo (Ciencia Al Poder) 2014-08-21 15:22:51 UTC
Well, Gerrit change #155560 is not exactly for warnings about existing files, but for any warning. This usually would do the trick. It's currently not possible to distinguish between different warnings without changing more things in site.py
Comment 3 John Mark Vandenberg 2014-08-21 15:46:24 UTC
It shouldnt be too difficult for api.py&site.py to provide upload.py with the exact warning received by the MW API.

Is this fix urgent?  Do you have a project that needs this checked in promptly, or can we work on trying to ignore only specific warnings?
Comment 4 Jesús Martínez Novo (Ciencia Al Poder) 2014-08-21 17:27:27 UTC
Well, I did that change to my code to bypass this limitation, and it worked very well, that's why I shared my code pushing the change to gerrit, so for me the issue is already solved :)

I'm not really fluent with python, since I've never worked before with it. I just know a bit of its syntax and changed the code to make it work, looking at how other parameters work. It could be improved to get the type of warning in the UploadWarning class, but I don't know if I'll be able to do that, so feel free to create a new patch solving this issue if you like
Comment 5 Gerrit Notification Bot 2014-08-22 03:51:32 UTC
Change 155560 merged by jenkins-bot:
upload.py: Add option to automatically abort upload on warning

https://gerrit.wikimedia.org/r/155560
Comment 6 Mpaa 2014-08-22 09:30:52 UTC
The type of warning is decoded into the exception message as follows:
        upload_warnings = {
            # map API warning codes to user error messages
            # %(msg)s will be replaced by message string from API responsse
            'duplicate-archive': "The file is a duplicate of a deleted file %(msg)s.",
            'was-deleted': "The file %(msg)s was previously deleted.",
            'emptyfile': "File %(msg)s is empty.",
            'exists': "File %(msg)s already exists.",
            'duplicate': "Uploaded file is a duplicate of %(msg)s.",
            'badfilename': "Target filename is invalid.",
            'filetype-unwanted-type': "File %(msg)s type is unwanted type.",
        }

So from the message, in a way, it is possile to understand the kind of warning.
If this is not clean enough, it can be improved further.
Comment 7 Jesús Martínez Novo (Ciencia Al Poder) 2014-08-22 10:12:26 UTC
Parsing a text is not very clean IMHO :)

I was expecting UploadWarning to have a property that will return the error key from the api (the key values from upload_warnings), that would be a good way to handle this
Comment 8 Fabian 2014-08-22 14:47:51 UTC
I would suggest to add a "code" to the UploadWarning which uses the keys of the upload_warnings dictionary.

So you could do something like:

try:
    site.upload(…)
except UploadWarning as e:
    if e.code == 'exists':
        # do stuff here: the file already exists

It's still 'parsing a text' but far easier, but maybe somebody has a better idea.
Comment 9 Jesús Martínez Novo (Ciencia Al Poder) 2014-08-22 15:07:43 UTC
Yes, that's what I was thinking. Maybe if I feel comfortable understanding how to do that I'll do that someday...
Comment 10 Fabian 2014-08-22 15:25:42 UTC
No worries, I'm currently working on a patch where you could simply parse the code.
Comment 11 Gerrit Notification Bot 2014-08-22 15:47:34 UTC
Change 155739 had a related patch set uploaded by XZise:
[FEAT] UploadWarning has uses the warning code

https://gerrit.wikimedia.org/r/155739
Comment 12 Gerrit Notification Bot 2014-08-22 17:15:08 UTC
Change 155739 merged by jenkins-bot:
[FEAT] UploadWarning uses the warning code

https://gerrit.wikimedia.org/r/155739

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links