Open Issues

The Markdown library has had a new release. It’s backwards-incompatible with the old ones, and Nikola breaks hard when using it. (v8.0.1 will probably be released later today to make things work when installing.)

Hi,
I am trying to iport a blog from blogger. I am getting the following error:
$ nikola import_blogger ~/Downloads/blog-04-08-2018.xml
[2018-04-08T09:20:51Z] ERROR: Nikola: In order to import Blogger dumps, you must install the "feedparser" Python package.
[2018-04-08T09:20:51Z] ERROR: Nikola: Exiting due to missing dependencies.
Can I use an external dependency, or does it need to be installed in the snap?

My initial experience with Nikola have not been positive. To improve the quality of the project, i've tried to summarize my experiences, in the hope this would become easier to use and faster to adopt for novices and advanced users alike.

1: The installation procedure for this project is not fit for beginning users. It misses a step in making it very explicit that you should create the content of your project OUTSIDE the virtual environment. It should be somehow clear that a virtual environment is disposable / rebuildable and in itself holds no value. At the same time the content is unique and special: it holds value as it cannot be easily recreated. Step 1 and 2 deliver a project inside the virtual environment, which makes no sense. There should perhaps be some directory traversing. (Also for Git users, uploading your whole virtual environment is not efficient at all).

2: The small box on the right side of the getting started page (with a series of commands) is a terrible abstraction: it is some sort of a decision tree a new user has to walk through. If you support multiple operating systems, make sure the whole procedure is listed in the installation guide for that operating system so the user doesn't have to think about it. What happens currently is that some text is "normalized" into a separate section, where in the normalization contains an "if" statement which cancels out the normalization. Just duplicate some parts of the manual so all instructions for installation could be copy-pasted and be of no further concern for a user. If you deduplicate, all and any steps are the same for all operating systems and there are no deviations. Otherwise, don't deduplicate.

3: The virtual environment commands might be abstracted away: having a choice depending on OS is not a great way to use Nikola on different platforms. Given it's somewhat trivial to determine the platform you're on etc, choosing the right virtualenv is trivial inside a script. Why would that burden be passed to an end user?

4: It is unclear how to continue working on a project when you've closed the virtual environment. As this is the most used functionality, it might be part of the "getting started", before the "next steps". Continuing to working on a project is currently a pretty big hurdle because it's not explicitly told what to do. Using commands like "source bin/activate" is not a natural thing to do for a novice. In what directory should that happen etc?... Some guidance would let novices continue their work with ease.

5: Case sensitivity (pedantry): is the project/tool called Nikola or nikola? The install page shows both, where it starts with "Nikola[extras]" first. It implies that you type things starting with a capital letter, including the Help command, which is then found wrong and a suggestion of "help" is offered. Just make a choice.