Octoprint: Octoprint is not starting due to a missing argument in a stock plugin after upgrade

[christianlupus]

What were you doing?

1. I updated OP to the latest GIT rc/maintenance version (fdf0f7)
2. I ran the python clean & install scripts
3. I started OP without success, both in normal and in safe mode

What did you expect to happen?

OP starts regularly and lets me access the web interface.

What happened instead?

OP refuses to start and aborts with an error message.

Did the same happen when running OctoPrint in safe mode?

Yes.

Version of OctoPrint

fdf0f75ffa5731fee406c6e761e84a9d2b47aa43

Operating System running OctoPrint

Raspbian jessie

Link to octoprint.log

https://gist.github.com/christianlupus/70a30f594161f7b6559f7355cf916116

Link to contents of terminal tab or serial.log

Not applicable as no server is run at all.

Link to contents of Javascript console in the browser

see above

I have read the FAQ.

[foosel]

How did you perform the upgrade? From the looks of your log, you didn't do it through OctoPrint's own software update plugin but rather manually?

This issue looks like you still have bits left of 1.3.6 (possibly in form of pyc files - forgot a python setup.py clean maybe?), if you look at the 1.3.9rc1 source you see that what your instance complains about there doesn't match the source.

[christianlupus]

I went to the folder where I installed OP. Then I used git to fetch and pull/merge the corresponding upstream branch. After that I called the python script in the virtual env first to clean and then to install it. My console history shows:

printer@printer:~/OctoPrint $ git pull
printer@printer:~/OctoPrint $ ./virt/bin/python setup.py clean
printer@printer:~/OctoPrint $ ./virt/bin/python setup.py install

[christianlupus]

I am just installing the RC again to check it again. Maybe there went something during the installation wrong. I will look for errors during installation.

[christianlupus]

OK, I tried it multiple times now. When installing the RC branch, I run into errors. You might be right, that there was a problem with partially deinstalled recent packages. After issuing the clean script I made a recursive listing (ls -R) of the OP installation directory. This showed quite a few occurrences of some OP related packages in ./virt/lib/python2.7/site-packages/. I thought that these packages should have been deleted by the clean script.
I put the relevant files here: https://gist.github.com/christianlupus/a3cf6e34cbd439893e92c379200d84e1 I did not see any errors in the logs.

Is it correct that the eggs are there still lying around? I am not familiar with the python installation scheme.
Is this intended behaviour?

[foosel]

python setup.py clean only cleans the stuff in your checkout folder, it will never touch your site packages. And a python setup.py install also won't remove older version, which is why the current instructions also say to use pip install . instead which does clear up old stuff still lying around.

Please try

cd ~/OctoPrint
./virt/bin/python setup.py clean
./virt/bin/pip install .

Or even better, use the built-in update procedure which no longer relies on git (removing one potential source of errors) and uses pip directly (removing the "left-overs" source of errors): https://discourse.octoprint.org/t/how-to-use-the-release-channels-to-help-test-release-candidates/402

[christianlupus]

I was working as described in this article. I think should be either updated or at least marked as out-of-date if this is the issue. I just ran pip and are waiting for the results...

[christianlupus]

@foosel That helped and now the OP server is running again. Thank you very much!

[foosel]

Ah... I knew I forgot something important to migrate to the new forum... Guide has been adjusted and moved to its new home.

[christianlupus]

@foosel The new text completely keeps git out of the text. Are you discouraging the users to clone the git repo directly and install as commit based solution?
Otherwise I would write a small comment on how to achieve git based installation as a reply to the topic on discourse. If you want to avoid people getting in touch with git (non-git users) I see your point and I would respect your wish to avoid confusing the normal user.

[foosel]

@christianlupus I've had too many people run into issues with corrupt git checkouts causing extremely hard to debug issues or update failures which I then get reported as bugs but can't do anything about. Which is also why I switched away from using it for updates entirely. So yeah - it's more or less discouraged now.