import_blogger possible bug

[stefanos82]

After I have initialized an empty project and installed import_blogger plugin I ran the following command:

nikola import_blogger /home/user/Documents/BLOGSPOT_BACKUPS/13-09-2016/demo_blog-09-13-2016.xml 
--output-folder=$HOME/tmp/PythonProjects/demo

The project is located in $HOME/tmp/PythonProjects named "example" and should have right next to it generated "demo". Instead, after I ran the aforementioned command, I have a new_site inside `$HOME/tmp/PythonProjects/demo" as sub-folder.

@ralsina As you have mentioned on IRC, this probably is a bug.

Also, can we do something about supporting --global flag with nikola plugin -i command?

I really need to have import_blogger as part of standard plugins, because installing it as --user is not convenient (at least to me) to have plugins or Python modules all over the place; that's why I use virtualenvwrapper, to keep things tight and organized.

Cheers.

[ralsina]

Weeeeeeeird, this seems to be a problem with option parsing!

Even when passing -o or --output-folder, options['output_folder'] is always the default.

[ralsina]

Aha! It works if the options are before the arguments!

So, this works:

nikola import_blogger -o foo whatever.xml

But this doesn't work:

nikola import_blogger whatever.xml -o foo

[ralsina]

@schettino72 is this known/expected behaviour?

[schettino72]

doit uses getopt.getopt https://docs.python.org/3/library/getopt.html#getopt.getopt

Note: Unlike GNU getopt(), after a non-option argument, all further arguments are considered also non-options. This is similar to the way non-GNU Unix systems work.

So, yes, this is the expected behavior.

[schettino72]

This behaviour is useful for example because the run command accepts different tasks as arguments, where each task can have its own parameters.

[Kwpolska]

Ah, the typical “not in GNU land anymore” realisation. (then again, I do rm directory -rf myself on systems where that fails.)

I’m closing this as wontfix.