octoprint running on dietpi will not install plugin BGCODE

[ruedli]

While the dietpi octoprint enabled configured all my plugins within octoprint, not BGCODE.

In order to install I had to (from root): apt install git apt install zlib1g apt install zlib1g-dev apt install build-essential

I also installed (but these seemed to be installed already): apt install cmake apt install gcc

Further I adapted .bashrc in both /root and /home/dietpi and included a line: export CXX=/usr/bin/gcc

The dietpi/octoprint documentation suggests that you could instead configure /etc/bashrc.d/dietpi-octoprint.sh but I did not verify this.

The vm on my n100 processor is incredibly fast compared to running on a Pi4. Besides that it can run other softwere: my homeassistant (with mqtt server and node-red from which you can interact with the printer) and pihole with (recursive dns), run in containers and there is space for additional windows 11 and ubuntu vm's.

Impressive

[MichaIng]

First of all, /etc/bashrc.d/dietpi-octoprint.sh is used to create the alias to call the OctoPrint CLI just via octoprint command, instead of manually using sudo and long paths. It runs on every interactive bash start, hence is not suitable for one-time actions, like installing build dependencies.

bgcode is an optional plugin, not preinstalled, is it? Generally it is expected that additional plugins may need additional build dependencies. Python wheels are compiled from source in those cases, no pre-compiled wheels hosted and downloaded. Only some are hosted as such on PyPI: https://pypi.org/project/OctoPrint-Wyze/#files

Further I adapted .bashrc in both /root and /home/dietpi and included a line: export CXX=/usr/bin/gcc

That should not be needed since build-essential pulls not only gcc, but also g++, the C++ compiler this variable can define. And since C != C++, using the C compiler for C++ builds should usually fail. The variable for C is CC but should not be needed to be set manually either, since build tools else use the (correct) default paths.

Does the documentation for this plugin not contain the required compilers and headers to install/build it?

[MichaIng]

For doing forward with this:

bgcode is an optional plugin, not preinstalled, is it?

If it is pre-installed, we would need to fix it in dietpi-software. If it is a plugin one can install afterwards, we could add a tab to the docs which states that for such cases, additional compilers or development headers might be needed, and the official plugin repo/docs or install/error logs checked, to find out which (there is no generic "solution" in this case).

[ruedli]

@MichaIng

If it is pre-installed,

No, it is not. binary gcode became a thing after octoprint, as such I can see why it was not in base octoprint. Still, given that many machines start to depend on it, I feel it should be supported. The other argument, is that "octopi" the Pi distro on which octoprint is installed, supports it which any special measures. From this perspective dietpi should mimic the same environment as octoprint: having an exception for one or more plugins is not logical from an octoprint user perspective where plugin installation should be straightforward and not require fiddling with the unix environment.

Having said all this: I am happy that I got everything working: dietpi is so much better! But at the same time I acknowledge that my steps to get it done are not optimal.

A simillar differce dietpi / octoprint is with respect to supporting webcams. I had to fiddle with that as well on dietpi.

[MichaIng]

From this perspective dietpi should mimic the same environment as octoprint

I wouldn't see it that way. The couter-argument is that we intentionally offer light and bare metal implementations of software, which is otherwise only available as pretty bloated full single-purpose OS images. Of course those images are more tailored and fully featured regarding this one software title, same like Home Assistant OS, LibreELEC and similar. Mimicing such cannot be a goal, but a minimal base installation in the first place, then considering each extension individually. There will always be more plugins available, this is why they are called "plugins".

having an exception for one or more plugins is not logical from an octoprint user perspective where plugin installation should be straightforward and not require fiddling with the unix environment.

That IMO is more a question about good documentation. Checking the docs: https://plugins.octoprint.org/plugins/bgcode/ Weird is that it covers the installation on Windows and Android only, not Linux. Likewise the GitHub repo: https://github.com/jneilliii/OctoPrint-BGCode

The other part is the OctoPrint install implementation. Not sure how it works and whether it has the infrastructure to take care about OS-based compiler/header dependencies as well.

Easiest would be of course if the project was on PyPI (Python Package Index), with pre-compiled wheels 🙂: https://github.com/jneilliii/OctoPrint-BGCode/issues/12

For now I think we'll add a section in our docs, stating the matter of plugin build dependencies in general, with the example of BGCode. If there are more votes to have this added natively, I may consider it. I'd then add the plugin itself, not (only) the build dependencies.

[ruedli]

@MichaIng

I wouldn't see it that way.

Well, I can for sure live with that. As long as people looking for a solution for BGCODE on a linux based implementation can find this information and learn about a solution. For me the solution above worked, I contacted jneilliii on this matter as to learn what could cause the problem I had. See: https://github.com/jneilliii/OctoPrint-BGCode/issues/11 and my remarks (as ruedli). jneilliii wanted for practical reasons to limit his support for compilation to the platform offered by octopi. His criterium was that it should compile there and if it would not compile on e.g. linux that should be researched and resolved by others. I feel this is his good right: what he invested in code for octoprint is formidable and in my opinion a huge contribution to the community. What you are contributing in dietpi is of also of such nature. So I am totally okay when some effort is left for others to explore :-)

He did provide my remark on the solution also discussed here with a "like" in his closed issue.

AND... still enjoying my dietpi container with octoprint on my N100 -as we talk-: it really flies on this platform!